Different Ways of Deployment in WM

Different ways of
deployment in
webMethods
Preeti Kalihari
1 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

Agenda
Introduction
Deployment Methods
Package Replication
wM Deployer

INTRODUCTION

Deployment
1. By mere definition for software deployment one means migration or

promotion of source code and configurations to other environment
for testing and debugging activities.
2. The process of deployment varies with respect to the process steps

depending upon the architecture and the infrastructure being
supported.
3. There are certain well defined process for deployment in

webMethods environment which have been discussed in detail in
the next slides.

Deployment Methods
There are two methods for deployment in webMethods :

1. Package Replication :
a. Package replication is used to copy (publish) packages from source

server to target server.
b. In a clustered environment, this feature is useful to quickly replicate new
and updated packages across all servers in the cluster.
2. webMethods Deployer :
a. webMethods Deployer is a tool you use to deploy assets that reside on

source webMethods servers to target webMethods servers.

Package Replication

Package Replication
Fig : Overview of Package Replication

Overview of Package Replication
1. During replication, a single Integration Server(referred as Publisher) sends
(publishes) a specified package to one or more recipient servers (referred
as Subscriber).
2. The server creates a distribution file that contains the package and
information about the package, and makes the package available to
subscribers, called as release.
3. Before sending a package to another server, we have to create a release.
4. Release can be of two type:
I. Patch Release: With a patch release, only the files included in the patch
release gets replaced along with their versions in the target package; all
other files in the target package remain intact.
II. Full Release: With a full release, the new package entirely replaces
the old package on the subscriber’s server.
Contd..
4. Subscribing servers receive the package in their inbound

directory(IntegrationServer_directory\replicate\inbound).
5. To activate the new package, an administrator on the subscribing

server must install the package after it arrives.
6. The Integration Server keeps track of package versions, Integration

Server versions, and JVM versions so that during package
installation the subscribing server can make sure the package being
installed is compatible with the subscribing server’s environment.

Version Checking
1.The target server is running the same or a later version of the JVM, as
specified during release creation.
2.If this requirement is not met, the subscribing server issues a warning and
installs the package but does not activate it. Administrator can later on hit the
‘Activate the inactivate packages’ option available on Admin console to
activate the package.
3.In case of full release, the version of the package on the target server is
earlier than or the same as the package being installed. If this requirement is
not met, package installation fails.
4.In case of patch release, the version of the package on the target server
exactly matches the version required by the release (as specified during
release creation). If this requirement is not met, package installation fails.

The Publishing Server
Tasks performed by publishing server are:
1. Displaying the list of subscribers for a package.
2. Specifying subscribers for a package.
3. Updating subscriber information.
4. Removing subscribers for a package.
5. Publishing a package to subscribing servers.
6. Specifying File and Version Information for a Release or Archive.

Publishing a Package
Publishing a package to other Integration Servers involves two tasks:
1. Creating a release :
a) After indicating the files to include in the release, the server places all
the selected files into a single, compressed file (a zip file).
b) It places the zip file in the

IntegrationServer_directory\replicate\outbound directory.
2. Sending the release
a) After creation of release,it will send to subscribing servers.
b) A subscribing server receives the zip file containing the release in its
inbound directory (IntegrationServer_directory\replicate\inbound).
c) The zip file remains in the inbound directory on the subscribing server
until the administrator of that server installs the package.
Package Replication

Package Replication

Package Replication

Package Replication

Package Replication

The Subscribing Server
Tasks performed by subscribing server are:
1. Displaying packages to which your server subscribes.
2. Manually Pulling a Package.
3. Subscribing to a package from another server.
4. Updating subscription information.
5. Canceling a subscription to a package on another server.
6. Installing a package that was published from another server.

Package Replication

Package Replication

WebMethods Deployer

WebMethods Deployer
1. webMethods Deployer is a tool you use to deploy items that reside

on source webMethods servers to target webMethods servers.
2. Items that deployer can deploy are:
a) Blaze Advisor rules.
b) webMethods Broker document types and client groups.
c) IS administration items such as ports, users, groups, and user‐created
scheduled tasks, packages, and Web Service Descriptors.
d) User‐created items such as pages, portlets, users, groups, roles, and
directory services.
e) Optimize process configuration such as process and step timeouts and
process extensions etc.
f) Trading Networks items such as processing rules, document types,
trading partner agreements, and partner profiles and security data.
g) Files from webMethods installations on machines that host an
Integration Server.

Deployment Steps
The deployment process involves these steps:
1. Create a deployment project by assigning the project a name,

setting the project’s properties, and authorizing users to work on the
project.
2. Define the project by identifying its contents.
3. Build the project.
4. Map the contents of the project to target servers.
5. Deploy the project to the target servers.

Set Default Properties for Projects
24
24 © 2013 WIPRO
© LTD | WWW.WIPRO.COM
2010 Wipro Ltd - Confidential| CONFIDENTIAL
1. The Deployer uses default properties for all projects. We can change
these properties.
2. Set the Default for Dependency Checking:
a. Automatic - Tells the Deployer to automatically check dependencies
regularly as we modify the project and progress through the different
phases of deployment.
b. Reduced - Tells the Deployer to automatically check dependencies when
we create a project build and when we deploy. We can trigger additional
dependency checking at different steps.
c. Manual - Trigger dependency checking at different steps ourself.

Set the Default Properties for Deployment

1. Checkpoint Creation - To have the Deployer automatically create a
checkpoint for a deployment candidate before it is deployed, click
Automatic. If you only want to generate checkpoints when you choose to
click Manual.
2. Roll back on Error - To have the Deployer automatically roll back a

deployment candidate after a failed deployment, click Automatic. If you
only want to roll back the project when you choose to click Manual.
3. Cluster Support - If you want to deploy to each Integration Server 7.1 in a

cluster yourself, click Manual.

Set Default Properties for Integration Server & Trading Networks Projects
Under the Suspend : During Deployment area, indicate whether the Deployer should
suspend activity for the Integration Server items listed below while deployment is going
on.
1. Triggers - Allow all running trigger operations to complete, then suspend all trigger
execution and document retrieval on the target Integration Servers is selecting All.
2. Ports - Whether to disable ports on the target Integration Servers that match ports
you are trying to deploy.
3. Scheduled Tasks - Whether to prevent scheduled tasks on the target Integration

Servers that match scheduled tasks you are trying to deploy from running.
4. Adapters - Not suspend adapter listeners or polling notifications if selecting None.

Create the Project
1. A deployment project identifies the items on source servers that we want

to deploy to target servers
2. To create a project, assign the project a name and set its properties;
then authorize users to perform the project tasks

Create the Project

Define the Project
1. When we define a project, create project deployment sets.
2. Each deployment set identifies items from source servers that you
want to deploy as a set to target servers
3. We can define these types of deployment sets within a single project.

a) Broker - Document types and client groups from multiple source brokers.
b) ProcessModel - Process models from one source ProcessModel

server.
c) IS & TN - IS administrative items, IS packages, and Trading Networks

items from multiple source Integration Servers
d) MWS - My webMethods Server items from multiple My webMethods

Servers.
e) Optimize - Analytic metadata from multiple Optimize servers

Defining an IS & TN Deployment Set

 Now select the server where our service is located
 Then click on Packages and select which service we want create deployment of



Manually Add Dependencies to a Package Component
1. Go to the Resolved Dependencies page.
2. Under the Manually Add Dependency area, in the Referenced

package box, type the name of the package that contains the
referenced component.
3. In the Referenced Component box, type the name of the

referenced component.
4. Click Add.

Building a Project
We build a project to create a file that contains the actual items that the
project definition points to.

Building a Project

Building a Project
 Export and Import a Build Using the Deployer Interface
1. Click Export.
2. The Deployer creates a file that contains the build. The file is named project_build
and is stored in the Integration
Server_directory\packages\WmDeployer\replicate\outbound folder
 Move the build into the target environment as follows :

1. Copy the project_build file to the Integration
Server_directory\packages\WmDeployer\replicate\inbound folder on the machine
that hosts the Deployer in the target environment.
2. In the Deployer in the target environment, go to the Tool -Import Build page.
3. In the Project Build list, click the project_build file you just copied to the inbound
directory.
4. Click Import.
Map the Project
1. It identifies the target servers for each deployment set the build
contains.
2. We can create multiple deployment maps for each project build.
3. We can also export the deployment maps and import them into
other projects.
4. We can define a target group to specify a set of target servers in an

environment.
5. If the Deployer in the source environment can also access the

target environment, we will be able to map the project build using
that Deployer.

Map the Project

Map the Project

Map the Project
 Change Configuration Parameters for IS & TN Deployment Set

1. configuration parameters in a project by asset type.
2. configuration parameters in a project by target servers.
 Import and Export Variable Substitutions for Asset Attributes
1. Export the configuration parameters from the project as follows:

a. Click Export Variable Substitution.
2. Move the build into the target environment as follows

a. Copy the project_map.vs file to the Integration
Server_directory\packages\WmDeployer\replicate\inbound folder on
the machine that hosts the Deployer in the target environment
3. Click Import Variable Substitution.

Deploying a Project

Deploying a Project

Deploying a Project
1. To deploy the project, click in the Deploy column for the

deployment candidate.
2. The Deployer does the following:
a. If you choose automatic check pointing or automatic roll back in
the project properties, automatically generates a checkpoint at
this time.
b. Deploys the items in the selected project build to the target
servers you identified in the selected deployment map
c. Creates a deployment report and lists the report in the
Deployment History area.

THANK YOU
Preeti Kalihari
Software Engineer
Preeti.kalihari@wipro.com

Different Ways of Deployment in WM

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Different Ways of Deployment in WM

Transféré par

Droits d'auteur :

Formats disponibles

Different ways of

1 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

2 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

3 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

1. By mere definition for software deployment one means migration or

2. The process of deployment varies with respect to the process steps

3. There are certain well defined process for deployment in

4 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

There are two methods for deployment in webMethods :

a. Package replication is used to copy (publish) packages from source

a. webMethods Deployer is a tool you use to deploy assets that reside on

5 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

6 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

Fig : Overview of Package Replication

7 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

3. Before sending a package to another server, we have to create a release.

4. Release can be of two type:

4. Subscribing servers receive the package in their inbound

5. To activate the new package, an administrator on the subscribing

6. The Integration Server keeps track of package versions, Integration

9 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

10 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

Tasks performed by publishing server are:

1. Displaying the list of subscribers for a package.

2. Specifying subscribers for a package.

3. Updating subscriber information.

4. Removing subscribers for a package.

5. Publishing a package to subscribing servers.

6. Specifying File and Version Information for a Release or Archive.

11 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

b) It places the zip file in the

2. Sending the release

a) After creation of release,it will send to subscribing servers.

13 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

14 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

15 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

16 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

17 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

Tasks performed by subscribing server are:

1. Displaying packages to which your server subscribes.

2. Manually Pulling a Package.

3. Subscribing to a package from another server.

4. Updating subscription information.

5. Canceling a subscription to a package on another server.

6. Installing a package that was published from another server.

18 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

19 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

20 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

21 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

1. webMethods Deployer is a tool you use to deploy items that reside

22 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

The deployment process involves these steps:

1. Create a deployment project by assigning the project a name,

2. Define the project by identifying its contents.

3. Build the project.

4. Map the contents of the project to target servers.

5. Deploy the project to the target servers.

23 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

25 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL

Set the Default Properties for Deployment

2. Roll back on Error - To have the Deployer automatically roll back a

3. Cluster Support - If you want to deploy to each Integration Server 7.1 in a

26 © 2013 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL