1. IBM UrbanCode Deploy v6.0 Plug-ins Middleware Configuration for WebSphere (MCWAS) v2
Update information in the top left
Replace red text with your enablement topic and change color back to black

2. Agenda Overview Changes from v1 Mapping UC Deploy Applications to WAS
Supported Scenarios
High Level Flow
Installation and configuration
Technical Details
UC Deploy Objects
Tokenization Process
Scenario Details
Demo
Roadmap
The bullets above represent the high level enablement requirements. For each topic, we should either state this requirement is NA or provide the appropriate information
Source: If applicable, describe source origin (date, author, publication) 2 2

3. UC Deploy v6.0 MCWAS v2 - Overview
Add capabilities to the IBM Urban Code Deploy (UCD) product that allow for WebSphere Application Server (WAS) configuration to be captured, associated with an Application and promoted across Environments
Used to automate deployments of applications hosted in WAS
Data driven approach that leverages WAS configuration templates
Create Cell, Cluster, Node, and Server scoped configuration templates based on an exemplar environment
Deploy application binaries and apply configuration templates to WAS instances via UCD processes
Detect configuration drift by scheduling periodic comparisons of a template against the live environment
Automatically discover WAS environments and create Resources in UCD
Resources represent the Cell topology and provide an infrastructure view of your environment
Resources centralize Cell configuration utilized by Process steps
Provide an overview of the topic, concepts, common scenarios, business value, etc. This can span more then one slide
Source: If applicable, describe source origin (date, author, publication) 3 3

4. UC Deploy v6.0 MCWAS v2 – Changes from v1
More scopes
In addition to Cell and Cluster, WAS configuration templates can now be captured from and applied to the Node or Server scope.
Configuration drift detection
Scenario: schedule a periodic comparison of my live WAS environment against the latest configuration template we’ve applied to it and notify me if any differences have been detected.
Changes may be accepted into the template, requiring the user to generate a new version
Changes may be rejected and the template reapplied to the WAS environment
New process in the Middleware Configuration for WebSphere Component Template named: Compare WebSphere configuration
Component Template
Is now packaged under the imports directory as opposed to jsonTemplates
This allows for it to be automatically imported in Deploy v6.0.1 server
Usability improvements for WAS configuration template generations
Most scenarios can now be supported completely inside of the Deploy server
New process in the Middleware Configuration for WebSphere Component Template named: Generate Template
Provide an overview of the topic, concepts, common scenarios, business value, etc. This can span more then one slide
Source: If applicable, describe source origin (date, author, publication) 4 4

5. UC Deploy v6.0 MCWAS v2 – Mapping UCD to WAS Applications (1 of 2)
1 UC Deploy Application Per WAS ND Cluster
Isolate application and configuration to the Cluster
Most common model for traditional WAS ND shops
UC Deploy Application contains binaries (e.g. EAR/WAR files) and a Cluster Scoped configuration template
Optionally includes configuration templates for Cell and Node scoped objects, shared by multiple applications
Exercise caution with configuration shared across applications to ensure no disruption during deployment
1 UC Deploy Application Per WAS Standalone Server
Isolate application and configuration to the Server scope
Applicable to those using WAS Base
UC Deploy Application contains binaries (e.g. EAR/WAR files) and a Server Scoped configuration template
Optionally includes configuration templates for Node scoped objects, possibly shared by multiple apps on Node 5 5

6. UC Deploy v6.0 MCWAS v2 – Mapping UCD to WAS Applications (2 of 2)
1 UC Deploy Application Per WAS ND Cell
Useful for short lived cells
Model typically used when provisioning in the Cloud
UC Deploy Application contains binaries (e.g. EAR/WAR files) and one WAS configuration template
Template represents cell scoped data
Middleware Administrator likely owns template
Possible for Application team to own if this model is used in Dev/Test environment
Layered Template Approach
Catch all for other scenarios
Configuration stored across any or all of Cell, Cluster, Node and Server scopes
All applicable configuration templates are associated with the Application and applied one at a time
Exercise caution with configuration shared across applications to ensure no disruption during deployment
1-to-1 mapping of template to scope (applying a template for a specific scope overwrites changes from any previous template for the same scope)
Can leverage steps in the Application Deployment for WebSphere plug-in to add targeted configuration on top of templates (e.g. middleware team may own the templates and app teams may apply some app specific configuration on top of them)
The Layered Template Approach is very similar to what Avnet calls the “kit” aproach, which was used at a number of customers. A central team owns the core or base templates which are provisioned first then any additional configuration that is required is added on top of those. For now, that additional configuration would be added using the steps available in the Application Deployment for WebSphere plug-in, and could include one or more wsadmin scripts stored as Components. 6 6

7. UC Deploy v6.0 MCWAS v2 - Supported Scenarios
Following scenarios are supported at the Cell, Cluster, Node and Server scopes:
Create/update WAS configuration template and publish to UC Deploy CodeStation
Automatically tokenize much of the information that is environment specific
Support for custom token creation and substitution
Deploy an Application containing other Components (EAR/WAS/etc.) and associated WAS configuration
Initial deployment and update of app binary and/or configuration template
Promote an Application Snapshot, including WAS configuration from one Environment to another
Rollback an Application and associated WAS configuration to a previous Snapshot
Compare a configuration template against the live environment, detecting drift and notifying interested parties of differences 7

8. UC Deploy v6.0 MCWAS v2 - High Level Flow
Middleware Administrator
-or-
Application Developer
IBM UrbanCode Deploy
Deployment Automation Developer
CodeStation
6 – Generate WAS Config Template
2 – Create Component
4– Define Deployment Process
Scenario assumes the following:
The Application Deployment for WebSphere and Middleware Configuration for WebSphere plug-ins have been loaded into your Deploy Server
The Middleware Configuration for WebSphere Component Template has been imported into your Deploy Server
WAS is installed in one or more environments for your application
A Deploy agent is installed at your DMGR (ND) or Server (BASE)
The Deployment Automation Developer has created the Application and Application Environments and works on the overall automation outside of this process, but coordinates and collaborates around how to include the WAS configuration template into the Application Processes
Import Plug-in Setup Resource Tree –The WAS plug-ins leverage Resources as centralized place to store configuration data that will be shared across Processes, for example, login credentials, paths to files, etc. Deployment Automation Developer or Middleware Administrator creates a Top Level Resource group, adding the agent on your DMGR or BASE Server. The Application Deployment for WebSphere plug-in will automatically discover the WebSphere cell and add it as a sub-resource to the agent. An option to auto-configure the cell will now be available, after specifying the absolute path to the target profile and login credentials the cell topology will be discovered and sub-resources of the cell (e.g. clusters, nodes, servers) will be created automatically.
Create Component - A Middleware Administrator or Application Developer creates a Component to store the WAS configuration template. The Component must inherit from the Middleware Configuration for WebSphere Component Template
Map Component to Resources - The Component is mapped to the Resources it will be imported from (the exemplar cell) or deployed to. Note that you must map it to the appropriate scope, for example, if you want to create a Cluster scoped template, then add the Component to a WebSphere Cluster Resource.
Create Application & Define Deployment Processes – The Deployment Automation Developer creates the Application, Application Environments and collaborates with the Middleware Administrator and/or Application Developer on how to integrate the WAS Configuration Template Component Processes
Add Component to Application and Resources to Application Environments – After working with the The Deployment Automation Developer on how the WAS Configuration Template Component will be used, the Middleware Administrator and/or Application Developer adds the Component to the Application, allowing for the Component Process to be added and enabling the completion of the Application Deployment Processes. It’s likely the WAS configuration is just one of several or many Components that comprise the overall structure of the Application (e.g. EAR files, etc.). Note that the Resources containing the configuration template must be added to the appropriate Application Environments
Generate WAS Configuration Template – to create the WAS configuration Template, go to the Application, click on Components and run the Process on the Component named Generate Template. The template will be generated for the Resource you select. Note that at this time you may need to review the files in the template to determine if any custom tokens will be required. If needed, follow the procedure below and generate the template again.
Inserting Custom Tokens into the WAS Configuration Template – The template generation process will automatically tokenize much of the information that is Environment specific (cell/node name/IP, etc.), however, there will likely be a need to tokenize other data that varies per environment, for example JDBC URLs (use a different DB in test then in production). The Middleware Administrator or Application Developer adds Component Environment Properties to the Component for each string they want to be tokenized during the template generation process. For example, if the exemplar cell has a JDBC URL that points to dev.foo.com you create a Component Environment Property with name websphere.jdbcURL1 and a default value of dev.foo.com. This will replace all instances of dev.foo.com with the token Component Environment Properties are added to each Application Evnironment that a Component is added to, this allows for you to enter a value to replace the token with during WAS configuration template deployment. For example, you may specify qa.foo.com for your QA environment and prod.foo.com for your production environment.
Deploy the WAS Configuration Template – To deploy the template, the Deployment Automation Developer must add the Configure WebSphere Application Server Component Process to an Application Process. You can the request the Application Process to be run in an Environment and the WAS configuration template will be downloaded and applied. Note that this may be initiated by a number of different people in different roles depending on the target Environment. It may also be scheduled to run automatically periodically or triggered by an event.
3 – Map Component to Resources
5– Add Component to Application
Resources
Dev Cell
Cluster1
Cluster2 …
QA Cell
Prod Cell
Components
EARs
WARs
PAAs …
SQL Scripts
Config Templates
Legacy scripts
App 1
EAR
DB Scripts
WAS Cell Cfg …
App 2
WAR
WAS Cluster Cfg
Applications
7 – Deploy Application
1 – Auto Discover & Configure
WAS
plug-ins
Application Environments
Prod QA
Dev
Exemplar

9. UC Deploy v6.0 MCWAS v2 - Installation and Configuration
Load the MCWAS plug-in
In the Deploy UI navigate to the Settings->Automation Plugins page
Click on the Load Plugin button, which will open a dialog box.
In the dialog box click the Choose File button and select the MCWASPlugin.zip file
The actual file may have a version appended to it (e.g. MCWASPlugin zip).
Click the Submit button
Import the Middleware Configuration for WebSphere Component Template
Unzip the contents of the MCWASPlugin.zip file
In the Deploy UI navigate to the Components->Templates
Click on the Import Template button, which will open a dialog box.
In the dialog box click the Choose File button and select the Middleware Configuration for WebSphere.json file, which will be under the imports directory where you unzipped the plug-in
Note that this import will happen automatically in the Deploy v6.0.1 server
The plug-in doesn’t require any explicit configuration other then to ensure your WAS instances have been modeled as Resources as described in the speaker notes of Slide 8. Additional details are also available in the InfoCenter
Source: If applicable, describe source origin (date, author, publication) 9 9

10. UC Deploy v6.0 MCWAS v2 – Technical Details
Several UC Deploy artifacts are required to support the scenarios on Slide 8
Artifacts that are shipped with the UC Deploy v6.0 product include:
Application Deployment for WebSphere Plug-in
Middleware Configuration for WebSphere Plug-in
Middleware Configuration for WebSphere Component Template
Artifacts that are generated at points within a scenario
Resources
Artifacts that are manually created
Top level Resource
Environment properties
Application
Components 10

11. UC Deploy v6.0 MCWAS v2 - Plug-ins
Middleware Configuration for WebSphere (MCWAS)
Exposes steps required to:
Generate WAS Configuration Templates
Apply WAS Configuration Templates
Compare WAS Configuration Templates against live WAS instances
Supports WAS v6.1, v7.0, v8.0 and v8.5
Application Deployment for WebSphere
Supports auto-discovery of WAS instances and auto-configuration of a the Resource tree
Exposes steps to:
Deployment of application binaries
Operational tasks (e.g. stop/start servers, etc.)
Common configuration tasks, supporting layered template approach (apply application specific configuration on top of base WAS template) 11

12. UC Deploy v6.0 MCWAS v2 – Resources (1 of 2)
WAS topologies will be auto-discovered on systems with a UC Deploy agent and represented as Resources. See InfoCenter or speaker notes for detailed procedure
In Urbancode Deploy, go to Resources.
Click Create Top-Level Group to create a group.
Add an agent.
Hover over the row for the resource group, click Actions, and select Add agent.
Wait 10 to 30 seconds, then click Refresh. A twisty is now next to the agent. When you expand it, there is a sub-resource cell, WebSphereCell.
Hover over the row, then click Edit.
Enter values for the following properties.
WebSphere Profile Path
WebSphere User
WebSphere Password. If this value is left blank, soap.properties is used to locate the password for the user.
Leave the Cell Name property blank.
Click Save.
Set Auto configure options for WebSphereCell.
Hover over the row for WebSphereCell, click Actions, then click Auto Configure.
Click No auto configure for resource.
Check Websphere Topology Discovery box.
Click OK.
Wait seconds, then click Refresh. A twisty is now next to WebSphereCell. Expand it and make sure the resource tree matches your WebSphere Application Server topology.
On the WebSphereCell entry, click Edit. Check that Cell Name was filled in and is correct. 12 12

13. UC Deploy v6.0 MCWAS v2 – Resources (1 of 2)
Required information (e.g. paths, login credentials, etc.) about WAS instances is centralized as Resource configuration and leveraged by the plug-ins during application and configuration deployment 13 13

14. UC Deploy v6.0 MCWAS v2 – Component Template
The Middleware Configuration for WebSphere Component Template includes Component Processes that perform common tasks and should not need to be modified.
All Components that contain WAS Configuration Templates should use this Component Template
The Component Template contains three processes:
Configure WebSphere Application Server
Applies the configuration template to the associated resource scope, replacing all tokens with the appropriate Component Environment properties
Compare WebSphere Configuration
Compares the configuration template to the live data of the associated Resource scope. The Process will succeed if there are no differences and fail if drift is detected. Details of the differences can be found in the Output Properties and Log for the step.
Generate Template
Creates a configuration template from the associated resource scope and creates a version for the associated component, automatically tokenizing known Environment specific information and allowing for custom tokens to be specified as Component Environment Properties. 14

15. UC Deploy v6.0 MCWAS v2 – Components
All WAS configuration templates will be represented in UC Deploy as Components
Components must be instances of the Middleware Configuration for WebSphere Component template
The configuration template files are stored in CodeStation
Custom tokens are defined as Component Environment Properties
The Components are added to both the Resource tree and Application
Note that CodeStation is not a substitute for version control. It’s recommended that you archive all your configuration templates or, check them into a supported source control system Artifact Cleanup System Settings will affect how long component versions are stored in CodeStation. 15 15

16. UC Deploy v6.0 MCWAS v2 – Applications
All UC Deploy Applications containing WAS configuration templates will have:
0 or 1 Cell, Cluster, Node and Server configuration templates
Applying a template destroys previous configuration so having two of the same scoped templates in one Application adds no value
It may be necessary to share Cell or Node scoped configuration templates across Applications, in these cases caution must be excercised to ensure no disruption to Applications during the deployment of others who share the same template.
There are no Applications, shipped with Deploy. They must be manually created by a Deployment Automation Developer 16

17. UC Deploy v6.0 MCWAS v2 – Tokenization (1 of 4)
Custom tokens are required where WAS configuration varies per Application Environment
We automatically detect and tokenize some data (hostnames, etc.)
Not possible to detect all Application specific data (e.g. WebSphere Variables, JDBC URLs, etc.)
Tokens are prefixed and suffixed with sign, for example, if the token name is JDBCURL it will appear as in your configuration template files
In general, users will generate an initial configuration template, then examine the files to determine what should be tokenized.
Once the tokens are identified, they are specified as Component Environment Properties
The name of the Property is the token name
The default value of the Property is the string to search and replace in the template
Component Environment Properties are automatically added to Application Environments when a Component is added to the Application
Edit the Environment Property to indicate the specific value to substitute for the token in that Environment
Common example is a URL to a database. It’s likely your production and test environments will use different databases but you want to deploy and test the same code
The Configure WebSphere Application server Process in the Middleware Configuration for WebSphere Component Template will automatically substitute tokens for the appropriate Environment Property value before apply the configuration template to your live WAS instance. 17

18. UC Deploy v6.0 MCWAS v2 – Tokenization (2 of 4)
Custom tokens are specified as Component Environment Properties 18

19. UC Deploy v6.0 MCWAS v2 – Tokenization (3 of 4)
Configuration Template (variables.xml) prior to tokenization
Configuration Template (variables.xml) after tokenization 19

20. UC Deploy v6.0 MCWAS v2 – Tokenization (4 of 4)
Top left: Application Environments
Top right: Production Environment
CLUSTER_VAR_VAL token will be replaced with “Production Cell”
Bottom right: QA Environment
CLUSTER_VAR_VALU token will be replaced with “QA Cell” 20

21. UC Deploy v6.0 MCWAS v2 – Scenario Details: Generate Template
Previous charts, including speaker notes, provides pre-requisite information
To generate a configuration template you:
Load the Application Deployment for WebSphere and Middleware Configuration for WebSphere plug-ins
Import the Middleware Configuration for WebSphere Component Template
Deploy agents to your WAS DMGR systems
Build out the Resource tree (see speaker notes on chart 13) for all WAS instances you need to interact with
Create a Component, make sure it uses the Middleware Configuration for WebSphere Component Template
Add custom tokens as Component Environment Properties
Map the Component to the appropriate sub-resource in the Resource tree
Template must be mapped to the correct scope, so if this is a cluster scoped template, you navigate to your Exemplar cell, expand sub-resources and click on “Actions->Add Component” for the cluster you want to use as your template, then add this Component
Create an Application and add the Component from the previous step
Click on the Components tab in the Application and click Run Process under actions
Select your exemplar Environment, the Component as the Resource, the Generate Template Process and the version
When the process completes the template will be uploaded to CodeStation and be visible under the Versions tab under the Component 21

22. UC Deploy v6.0 MCWAS v2 – WAS Configuration Template Creation
Middleware Administrator
-or-
Application Developer
IBM UrbanCode Deploy
Deployment Automation Developer
CodeStation
2 – Create Component
4– Create Application
Scenario assumes the following:
The Application Deployment for WebSphere and Middleware Configuration for WebSphere plug-ins have been loaded into your Deploy Server
The Middleware Configuration for WebSphere Component Template has been imported into your Deploy Server
WAS is installed in one or more environments for your application
A Deploy agent is installed at your DMGR (ND) or Server (BASE)
The Deployment Automation Developer has created the Application and Application Environments and works on the overall automation outside of this process, but coordinates and collaborates around how to include the WAS configuration template into the Application Processes
Import Plug-in Setup Resource Tree –The WAS plug-ins leverage Resources as centralized place to store configuration data that will be shared across Processes, for example, login credentials, paths to files, etc. Deployment Automation Developer or Middleware Administrator creates a Top Level Resource group, adding the agent on your DMGR or BASE Server. The Application Deployment for WebSphere plug-in will automatically discover the WebSphere cell and add it as a sub-resource to the agent. An option to auto-configure the cell will now be available, after specifying the absolute path to the target profile and login credentials the cell topology will be discovered and sub-resources of the cell (e.g. clusters, nodes, servers) will be created automatically.
Create Component - A Middleware Administrator or Application Developer creates a Component to store the WAS configuration template. The Component must inherit from the Middleware Configuration for WebSphere Component Template
Map Component to Resources - The Component is mapped to the Resources it will be imported from (the exemplar cell) or deployed to. Note that you must map it to the appropriate scope, for example, if you want to create a Cluster scoped template, then add the Component to a WebSphere Cluster Resource.
Create Application – At this point, you just need to ensure there is an Application and that the Component has been added to it. This will enable you to run the template generation Component Template Process. he Deployment Automation Developer creates the Application, Application Environments and collaborates with the Middleware Administrator and/or Application Developer on how to integrate the Generate Template Component Processes
Add Component to Application and Resources to Application Environments – After working with the The Deployment Automation Developer on how the WAS Configuration Template Component will be used, the Middleware Administrator and/or Application Developer adds the Component to the Application, allowing for the Component Process to be added and enabling the completion of the Application Deployment Processes. It’s likely the WAS configuration is just one of several or many Components that comprise the overall structure of the Application (e.g. EAR files, etc.). Note that the Resources containing the configuration template must be added to the appropriate Application Environments
Generate WAS Configuration Template – to create the WAS configuration Template, go to the Application, click on Components and run the Process on the Component named Generate Template. The template will be generated for the Resource you select. Note that at this time you may need to review the files in the template to determine if any custom tokens will be required. If needed, follow the procedure below and generate the template again.
Inserting Custom Tokens into the WAS Configuration Template – The template generation process will automatically tokenize much of the information that is Environment specific (cell/node name/IP, etc.), however, there will likely be a need to tokenize other data that varies per environment, for example JDBC URLs (use a different DB in test then in production). The Middleware Administrator or Application Developer adds Component Environment Properties to the Component for each string they want to be tokenized during the template generation process. For example, if the exemplar cell has a JDBC URL that points to dev.foo.com you create a Component Environment Property with name websphere.jdbcURL1 and a default value of dev.foo.com. This will replace all instances of dev.foo.com with the token Component Environment Properties are added to each Application Evnironment that a Component is added to, this allows for you to enter a value to replace the token with during WAS configuration template deployment. For example, you may specify qa.foo.com for your QA environment and prod.foo.com for your production environment.
3 – Map Component to Resources
5– Add Component to Application
Resources
Dev Cell
Cluster1
Cluster2 …
QA Cell
Prod Cell
Components
EARs
WARs
PAAs …
SQL Scripts
Config Templates
Legacy scripts
App 1
EAR
DB Scripts
WAS Cell Cfg …
App 2
WAR
WAS Cluster Cfg
Applications
6 – Generate WAS Config Template
1 – Auto Discover & Configure
WAS
plug-ins
Application Environments
Prod QA
Dev
Exemplar

23. UC Deploy v6.0 MCWAS v2 – Scenario Details: Deploy Template
Previous charts, and completion of the template generation scenario are pre-requisites to this
To deploy a configuration template you:
Map the Component to the appropriate sub-resource in the Resource tree
Template must be mapped to the correct scope, so if this is a cluster scoped template, you navigate to the Cell you want to deploy to and expand sub-resources and click on “Actions->Add Component” on the appropriate cluster, then add this Component
Create an Environment in your application that represents your deployment target (e.g. QA, Staging, Production, etc.)
Click on the Environment and:
Add Base Resources button, select the Component you mapped 2 steps previous
If you created custom tokens during template generation, you’ll see them listed under Configuration- >Environment Properties. Specify the values you wish to use in this environment
In the Application, create a Process and in the process designer drag the Install Component step
Select the Component and the Configure WebSphere Application Server Component Process
Add any other steps you need
In the Application, click the Run Process button next to the Environment and select the Process created in the previous step 23

24. UC Deploy v6.0 MCWAS v2 – Applying a WAS Configuration Template
IBM UrbanCode Deploy
Automator
Resources
Dev Cell
Cluster1
Cluster2 …
QA Cell
Prod Cell
Environments
Contain
WAS Configuration Templates
Other deployable artifacts
CodeStation
1– Initiate Deployment Process (all other steps are performed automatically)
Scenario assumes the following:
The Application Deployment for WebSphere and Middleware Configuration for WebSphere plug-ins have been loaded into your Deploy Server
The Middleware Configuration for WebSphere Component Template has been imported into your Deploy Server
WAS is installed in one or more environments for your application
A Deploy agent is installed at your DMGR (ND) or Server (BASE)
The Application, including Environments, WAS configuration template Components and Processes have been created (note that the deployment Application Process will likely contain the WAS configuration template Component Template Process named Configure WebSphere Application Server as well as deployment process for other Components (e.g. to install an EAR, update DB schema, etc.)
The Automator initiates the Application Deployment Process. The Application Process will contain the Configure WebSphere Application Server Component Template Process as one step, all other potential steps in the Process are ignored for simplicity (e.g. may be steps to deploy EAR files, apply database updates, etc.). Note that this may be initiated by a number of different people in different roles depending on the target Environment. It may also be scheduled to run automatically periodically or triggered by an event. Everything after this step happens automatically.
The WAS configuration template will be downloaded from CodeStation to the target system (WAS DMGR or Server)
We discover information about that WAS instance, including it’s topology and Environment specific information (hostnames, node names, etc.)
The WAS configuration template is instatiated based on the information we discovered in the previous step
All custom tokens are substituted for
The template is applied to the WAS instance at the scope the Component is mapped to in the Resource tree. Note that when applying a template, we tear down the previous configuration and build it back up to match the template exactly, this is a “destructive install” and gaurantees that the configuration will match the template
Mapped
Components
EARs
WARs
PAAs …
SQL Scripts
Config Templates
Legacy scripts
App 1
EAR
DB Scripts
WAS Cell Cfg …
App 2
WAR
WAS Cluster Cfg
Applications
Included
WAS discovery
Template instantiation
Custom token substitution
Template applied to scope
2 – WAS Configuration Templates Downloaded to Resource
WAS
plug-ins
Application Environments
Prod QA
Dev
Exemplar

25. UC Deploy v6.0 MCWAS v2 – Scenario Details: Configuration Drift
Previous charts, and completion of the template generation and deployment scenarios are pre-requisites to this
To compare a template against a live WAS instance you:
Click on the Components tab in the Application and click Run Process under actions (for the Configuration Template Component)
Select theEnvironment and Resource that correspond to the live WAS instance you want to compare, select the Compare WebSphere configuration Process and the version of the template to compare to the live instance
The Process will succeed if there are no differences and fail if drift was detected
To see the differences you navigate to the Process Request and open the Input/Output Properties, which will summarize the differences and the lines to look at in the Output log for details
If the change is desireable you can create a new instance of your template using this Environment, or, update your Exemplar environment and generate a template from it
It the change was erroneous, you can rollback to the template using the deployment process
Typically, you’ll wrap this Component process in an Application Process and schedule it to run periodically (e.g. nightly) and setup notifications if the process fails. 25

26. UC Deploy v6.0 MCWAS v2 – Configuration Drift Detection
IBM UrbanCode Deploy
Automator
Resources
Dev Cell
Cluster1
Cluster2 …
QA Cell
Prod Cell
Environments
Contain
WAS Configuration Templates
Other deployable artifacts
CodeStation
1– Initiate Compare Process (all other steps are performed automatically)
Scenario assumes the following:
The Application Deployment for WebSphere and Middleware Configuration for WebSphere plug-ins have been loaded into your Deploy Server
The Middleware Configuration for WebSphere Component Template has been imported into your Deploy Server
WAS is installed in one or more environments for your application
A Deploy agent is installed at your DMGR (ND) or Server (BASE)
The Application, including Environments, WAS configuration template Components and Processes have been created (note that the deployment Application Process will likely contain the WAS configuration template Component Template Process named Configure WebSphere Application Server as well as deployment process for other Components (e.g. to install an EAR, update DB schema, etc.)
The Automator initiates the Application Deployment Process. The Application Process will contain the Configure WebSphere Application Server Component Template Process as one step, all other potential steps in the Process are ignored for simplicity (e.g. may be steps to deploy EAR files, apply database updates, etc.). Note that this may be initiated by a number of different people in different roles depending on the target Environment. It may also be scheduled to run automatically periodically or triggered by an event. Everything after this step happens automatically.
The WAS configuration template will be downloaded from CodeStation to the target system (WAS DMGR or Server)
We discover information about that WAS instance, including it’s topology and Environment specific information (hostnames, node names, etc.)
The WAS configuration template is instatiated based on the information we discovered in the previous step
All custom tokens are substituted for
The template is compared to the live WAS instance data. If they match exactly the Application Process will succeed, if there’s a difference, the Process will fail. A summary of the differences is included in the Step Output Properties and the details are included in the Step Output Log.
Mapped
Components
EARs
WARs
PAAs …
SQL Scripts
Config Templates
Legacy scripts
App 1
EAR
DB Scripts
WAS Cell Cfg …
App 2
WAR
WAS Cluster Cfg
Applications
Included
WAS discovery
Template instantiation
Custom token substitution
Template compared to live WAS instance
2 – WAS Configuration Templates Downloaded to Resource
WAS
plug-ins
Application Environments
Prod QA
Dev
Exemplar

27. UC Deploy v6.0 MCWAS v2 – Scenario Details: Configuration Drift27

28.
General demo of capability, but here are some specifics support is looking for
a. Identify and discuss the use cases that are conveyed to the Client, so that Support knows what is driving the Client to install/upgrade to this product.
Identify, discuss, and demo any new and/or revised features and functionality.
Identify and discuss any features and functionality that have been removed. 28 28

29. UC Deploy MCWAS Plug-in: Roadmap*
September
Initial plug-in release
Cell scoped templates
Cluster scoped templates
Create, deploy, promote, rollback template
November
Node scoped templates
Server scoped templates
Configuration drift detection
Template creation UX improvements
December
Cell-to-Cell compare
Performance improvements
XPath tokenization
Backlog
Update mode
Topology build out
Template UI
Improvements to layered template approach
Enhanced application deployment support
WAS Migration
* Information pertaining to new capabilities s is for informational purposes only, is not a commitment, promise, or legal obligation to deliver any material, code or functionality, and may not be incorporated into any contract. The development, release, and timing of the MCWAS lug-in remains at our sole discretion.
IBM Confidential: NDA

30. Author Note: Mandatory Rational closing slide (includes appropriate legal disclaimer). Graphic is available in English only.
© Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 30 30

31. www.ibm.com/software/rational Keep this as the last chart in the deck31 31

32. Backup

33. UC Deploy v6.0 MCWAS v2 - Migration and Upgrade Process
Updating the plug-in
Procedure is the same as the initial load. See slide 9 for details
Updating the component template
Procedure is the same as the initial import, but you must select the Upgrade Template checkbox
Note that customers of RAF may ask if they can leverage RAF assets within MCWAS
Cell, Cluster, Node and Server scoped templates produced by the RAF v3.0.1 Eclipse client can be used with MCWAS v2
In this scenario, the RAF templates can be placed into CodeStation as a Component using any supported Source Config Type.
RAF can continue to be used for managing configuration (import, compare, etc.) and Deploy for deployment
This hybrid environment should be considered transitional and only used to facilitate a complete migration to Deploy. Do not advocate this as a long term or strategic solution.
Source: If applicable, describe source origin (date, author, publication) 33 33

34. WAS Configuration Template Creation
UC Deploy v6.0 MCWAS v1 - High Level Flow (read speaker notes for details)
WAS Configuration Template Creation
Middleware Administrator
-or-
Application Developer
Deployment Automation Developer
CodeStation
2 – Plug-in
6 – Define Deployment Process
3 - Import
4 - Assemble
Note that this flow is only required in the case of “over tokenization”, that is, if specifying the strings to replace with tokens using the process defined on slide 8 doesn’t provide enough control, resulting in strings being tokenized that shouldn’t be. For example, one may want to tokenize a port, such as “80”, but specifying “80” as a string to replace in the Component Environment Properties tokenizes strings that you didn’t expect or didn’t want. For these cases, you will need to manually insert the tokens into the desired XML file. You will continue to need to use Component Environment Properties to substitute. Note, that in a future release, we’ll likely allow for an XPath expression instead of just a String (e.g. “80”), which will provide more control over what is and what isn’t tokenized.
Deployment Automation Developer or Middleware Administrator imports the Application Deployment for WebSphere and Middleware Configuration for WebSphere (MCWAS) Plug-ins into the Deploy server, imports the Middleware Configuration for WebSphere Component Template, installs an agent to the server where the WAS Deployment Manager is running and creates a Top Level Resource group, adding the Deployment Manager agent. The Application Deployment for WebSphere plug-in will automatically discover the WebSphere cell and add it as a sub-resource to the agent. An option to auto-configure the cell will now be available, after specifying the absolute path to the target profile and login credentials the cell topology will be discovered and sub-resources of the cell (e.g. clusters, nodes, servers) will be created automatically.
A Middleware Administrator or Application Developer unzips the MCWAS plug-in on a system that has connectivity to the exemplar WAS cell
The Middleware Administrator or Application Developer runs the genWASTemplates script packaged in the MCWAS plug-in, which prompts for some information, then discovers and imports configuration from the exemplar WAS cell
The genWASTemplates script will create a WebSphere Configuration Template for all scopes or specified scopes in the cell. Note that if there is any Environment specific information (e.g. JDBC URL), you’ll need to create a custom token entry in the template’s promote.properties file (genWASTemplate will pause to provide an opportunity to do this). Custom tokens are substituted with the values of Application Environment properties during configuration template deployment. The Environment properties must be prefixed with “websphere.” and match the token name. For example, if you have a JDBC URL that varies per environment and the value in the exemplar cell is exemplar.foo.com the you would create an entry in the promote.properties file that looks like “JDBC_URL=exemplar.foo.com”. This will search in all template files for the string “exemplar.foo.com” and replace it with the token This is a dumb search and replace so you need to be careful you don’t specify a string that is too small/generic, otherwise it will tokenize more data then you intended. If this happens you should not make an entry for the token in the promote.properties file but edit the XML files directly. Note that this is not directly shown in the diagram above for the sake of clarity.
The MCWAS plug-in contains a script named createUCDObjects which will create a Component in Deploy and store the configuration in CodeStation. The Component will be associated with the Middleware Configuration for WebSphere Component Template. Note that the script will allow you to specify an existing template and update the version in CodeStation. If you created any custom tokens in the previous step, you will need to create Component Environment Variables to property substitute for them. The name of the Component Environment Property should be the name of the token, prefixed by “websphere.” To follow the previous example, the name would be “websphere.JDBC_URL”. You can specify a default value for this Component Environment Property but the real power comes with specifying different values per Environment, which you can do by clicking on the Application Environment->Configuration->Environment Properties. For example, you may have a value of production.foo.com for your production Environment and test.foo.com for your QA Environment.
The Deployment Automation Developer should now have all the Deploy artifacts he needs to assemble the Application automation including
The Application, including WAS configuration, can be deployed and promoted across all Environments defined in the Application
5 - Publish
App 1
EAR
DB Scripts
WAS Cell Cfg …
App 2
WAR
WAS Cluster Cfg
Applications
Exemplar WAS Cell
7 - Deploy
7 - Deploy
7 - Deploy
WAS Configuration Templates
Resources
Dev Cell
Cluster1
Cluster2 …
QA Cell
Prod Cell
Application Environments QA
Prod
Dev
WAS
plug-ins
1 – Auto Discover & Configure