Applying and removing partial configurations
This article was originaly published in 2017.02.02
The IBM® WebSphere® Application Server – Configure plug-in can modify the whole WebSphere Application Server configuration or a part of it by targeting specific objects. Applying a configuration at the object level is especially useful when the target object is located deep in the application server configuration hierarchy, such as in a cell, node, or server. By targeting these objects, you can target specific configuration objects and leave others untouched.
Configuration data, which is provided by a
code-snippet.json file, might include one or more objects of the same or different types. Furthermore, with this step, users can selectively choose which object types to update. Similarly, you can take full WebSphere Application Server configuration data—that is, the entire cell, node, or server configuration—and modify the objects of certain types in the target scope.
By using the WebSphere Configuration Partial Apply step and the WebSphere Configuration Partial Remove step, you can add, update, and remove individual WebSphere configuration objects.
The WebSphere Configuration Partial Apply step
In version 47, a step was added to the plug-in, which is named WebSphere Configuration Partial Apply.
This step only creates or updates configuration objects of the specified types. If the configuration data contains objects of these types, those objects can be created or updated.
To control which object types are created or updated, use the step’s WebSphere Configuration Types property field. When you specify values in this field, the create or apply scope is limited to the specified object types. Furthermore, the apply scope affects only the cells, nodes, or servers at and lower than the selected object.
If the field is blank, any object types that are both supported by this feature and present in the configuration data are created or updated.
For example, you have a
Cell.json file, which contains configuration data for the entire cell. You want to update the JAASAuthData
settings, but you don’t want to change any other objects, even though this new step can also update
KeyStores and
DynamicSSLConfigSelection objects and so on. To limit the changes to JAASAuthData objects, specify only the
JAASAuthData object in the WebSphere Configuration Types field. Say that this full
Cell.json file contains many configuration objects and is hundreds of lines long. If you specify the
JAASAuthData object type in the
Configuration Types field, only the
JAASAuthData objects in the
Cell.json file are created or updated. The rest of the
Cell.json file is ignored.
This result might be helpful if you don’t want to break the
JAASAuthData objects into snippets. You can also use this effect to apply to most of a
Cell.json file, while ignoring other pieces. For example, if you apply to the
Cell.json file all the supported types in the configuration types field except the
JAASAuthData type, the other objects are created or updated, and the
JAASAuthData objects are ignored.
Supported WebSphere objects types
- CORBAObjectNameSpaceBinding
- CustomUserRegistry
- DataReplicationDomain
- DataSource
- DynamicSSLConfigSelection
- EjbNameSpaceBinding
- ForeignCell
- GenericJMSConnectionFactory
- GenericJMSDestinationm
- HealthClass
- HealthController
- IndirectLookupNameSpaceBinding
- J2CActivationSpec
- J2CAdminObject
- J2CConnectionFactory
- JAASAuthData
- JAASConfigurationEntry
- JavaProcessDef
- JDBCProvider
- JMSProvider
- KeyStore (and TrustStore)
- KRB5
- LDAPUserRegistry
- Library
- LocalOSUserRegistry
- MQConnectionFactory
- MQQueue
- MQQueueConnectionFactory
- MQTopic
- MQTopicConnectionFactory
- Property (Security Custom Property)
- SIBus
- SingleSignon
- SPNEGO
- SSLConfig
- SSLConfigGroup
- StringNameSpaceBinding
- TAInterceptor
- TimerManagerInfo
- TrustedAuthenticationRealm
- TrustManager
- URL
- VariableMap
- VirtualHost
- WASQueue
- WASQueueConnectionFactory
- WASTopic
- WASTopicConnectionFactory
- WIMUserRegistry
- WorkManagerInfo
Limitations
- A limited number of objects is supported
- Objects may only be applied at a specific WebSphere scope (Cell/Node/Server/Cluster)
- For example, configuration files representing JDBC providers at the server scope and the node scope may not be applied at the same time.
- The live compare feature still requires full configuration data at the cell, node, server, or cluster scope to work. Applying a snippet without merging it with the full configuration data causes live compare to show differences
- Although health controller configuration is supported, health controller prohibited restart times cannot be changed by using the wsadmin command. Therefore, the plug-in does not support discovering or changing these values. For more information, see Intelligent Management: health controller commands with the AdminConfig object.
The WebSphere Configuration Partial Remove step
In version 49 of the plug-in, a new step named WebSphere Configuration Partial Remove was introduced. Like the WebSphere Configuration Partial Apply step, the WebSphere Configuration Partial Remove step runs against a file of configuration data. If the configuration data contains any objects of the specified object types, they will be removed from your WebSphere configuration.
To control which object types are removed, use the step’s WebSphere Configuration Types property field. When you specify values in this field, the remove scope is limited to the specified object types. If the field is blank, any object of an object type that is supported by this feature and that is present in the configuration data is removed.
See
Supported WebSphere objects types. These are the same object types that the partial apply step supports.
See
Limitations. The same limits apply to the partial apply step.
#WebSphereApplicationServer(WAS)#UrbanCodeDeploy