Synchrony Platform 4.4 DeploymentGuide AllOS en

SYNCHRONY DEPLOYMENT GUIDE
Synchrony platform
Version 4.4
March 24, 2011
Copyright 2011 Axway Software S.A. All rights reserved. This documentation describes the following Axway software: Synchrony platform No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway Software S.A. This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functions of this product. Axway Software S.A. may change this publication, the pro uct described d herein, or both. These changes will be incorporated in new versions of this document. Axway Software S.A. does not warrant that this document is error free. Axway Software S.A. recognizes the rights of the holders of all trademarks used in its publications. The documentation may provide hyperlinks to thirdparty web sites or access to thirdparty content. Links and access to these sites are provided for your convenience only. Axway Software S.A. does not control, endorse or guarantee content found in such sites. Axway Software S.A. is not responsible for any content, associated links, resources or services associated with a thirdparty site. Axway Software S.A. shall not be liable for any loss or damage of any sort associated with your use of thirdparty content.
Contents
1 Overview Terminology Deploymentcompatible components Disconnected versus connected deployment Deployment workflow 2 Using Composer as the design tool Designing configurations Creating Deployment containers Deployment container structure Example of a Deployment container Editing the Deployment container Example of a component.xml file Example of an attributes.xml file 3 Specializing using the File Update Tool Basic concept Launching the tool Settings file Log file management Specialization process Identification rules file 4 Deploying containers Overview Server commands Import Remove List Detail Help Clean Export 5 Deploying to Integrator About the deployment lifecyle Deployment lifecycle process Connect or disconnect Composer Linking an Integrator Server to Composer Servermode commands Deploying Containers Prerequisites 5 5 5 6 6 9 9 9 10 10 11 11 12 15 15 16 16 17 17 20 27 27 27 27 28 28 28 28 29 29 31 31 32 33 34 34 34 35
Synchrony Platform 4.4
Deployment Guide iii
Deployment commands Which objects can you deploy, and when? Updating and dependant objects About Integrator versioning About the update option About Container and object dependancy Deployment examples Example 1: Firsttime deployment Example 2: Deploy a dependant Container Example 3: Remove Container that has dependant Containers Example 4: Remove Container without dependant Containers Example 5: Deploy dependant Container with newer version of dependant object Example 6: Update dependant object used by other objects Rolling back to earlier versions Example: Rolling back to an earlier Container Example: Rolling back to an earlier server configuration Managing Integrator deployment packages remotely Installing the batch importer tool Using the batch importer tool Importing to a server with a different OS Consecutive imports Integrator attribute names 6 Deploying to ProcessManager Architecture Functionalities The Export Deployment Container Container overview Attributes.xml Export Files 7 Deploying to Sentinel Deployment commands Sentinel attributes management 8 Auditing deployment Tracked objects ServerLog TO attributes Deployment TO attributes Activating deployment monitoring for Composer 9 Using Composer for maintenance In connected mode In disconnected mode
35 39 41 42 42 43 43 43 44 45 45 46 46 47 47 48 48 48 49 49 49 50 53 53 53 54 54 55 57 59 59 59 61 61 61 61 62 63 63 63
iv Deployment Guide
Overview
This chapter provides an overview of the deployment functionality.
Terminology
l
Axway component: An Axway component is a software application developed by Axway and potentially included in the Synchrony platform.
Deployment container: A deployment container is a package generated by a design tool that includes all the physical elements (properties file, implementation settings and so on) necessary for the dynamic configuration of Axway components.
Environment: An environment is a set of system resources (machine, port, database, and so on) and the runtime part of Axway components.
Implementation settings:
l l l l
Integrator: IntegrationTasks, IntegratorProcesses, MapStages ProcessManager: Business processes Sentinel: Monitoring requests, Dashboards Accounting Integrator: Rules
Specialization: Runtime configuration of servers.
Deployment-compatible components
The deployment functionality can be used with the following Synchrony 4.4 platform components using Composer as the deployment tool: Component Axway Composer Axway AccountingIntegrator Axway Integrator Axway ProcessManager Axway Sentinel Version 3.7 1.6 3.6 2.3 3.5
For additional information on the deploymentrelated specificities of each Axway component, refer to the Componentspecific information section.
Deployment Guide 5
1 Overview
In addition, Axway EZBP can be used to create containers deployable to ProcessManager, and Axway Mapping Services can be used to create containers deployable to Integrator. Details of how to use EZBP and Mapping Services as deployment design tool are provided in the componentspecific documentation.
Disconnected versus connected deployment

The disconnected deployment functionality described in this document fulfils the same objective as a Composer broadcast operation or Send to Server command, but without requiring a connection between Composer and the runtime environment. Therefore disconnected deployment mode enables you to break the communication link between Composer and the component server or Broadcast Agent, and still transfer Composer objects between the separate entities. The connected mode is best used for the design and simulation phases. However, once you have finalized your configuration design, instead of transferring it directly via a broadcast operation or Send to Server command, you create a configuration container.
Deployment workflow
The Synchrony deployment functionality enables you to deploy a given Synchrony platform configuration in several environments. For example, you can validate a configuration in a test environment and then subsequently deploy that configuration to preproduction and/or production environments. The following diagram illustrates a typical workflow for deployment:
Figure 1. A simplified overview of the Synchrony deployment lifecycle The example illustrates the entire deployment workflow, from an installation performed on several environments, to the actual deployment phase of validated configurations.
6 Deployment Guide
Deployment workflow
1. In Composer, create and update a dynamic Axway component configuration. You then broadcast the configuration to a Axway server (The Development environment) for testing and validation: the new configuration is directly taken into account and easily removed from the server. 2. Once validated in Development, export your configuration to a container. This container holds all the dynamic runtime configuration information and an attributes.xml file that contains all the data specific to the environment such as the host name, IP port, URL to the database, and so on. 3. Deploy this container onto an Axway server in a Preproduction environment using a third party deployment tool. . Specialize the attributes.xml file to match the technical infrastructure of the target environment (the rest of the container must not be modified) using the File update Tool. 4. Once validated in Preproduction, deploy this same container to a Production environment using a third party deployment tool. . Specialize the attributes.xml file. Note For the Preproduction and Production environments, no design tool is connected. The only way to add or replace a configuration is to deploy a container.
The list of commands that can be passed on Axway components is provided in the Server commands section. The entire workflow can be monitored using the Axway Sentinel. For this, two Tracked Objects can be used: ServerLog and Deployment. For details about these objects, refer to the Auditing deployment section. Note In parallel of the deployment tool, you can use source control software to save and restore all the data deployed.
Deployment Guide 7
1 Overview
8 Deployment Guide
Using Composer as the design tool
This chapter describes how Axway Composer can be used in the deployment operation.
Designing configurations
In the Synchrony platform, the design tool is Axway Composer. The contents of the deployment containers can therefore be defined in Composer.
l
The Topography workbench is where you design the static portion your infrastructure, that is, the physical communication attributes for each Axway component (network type, protocol, operating system, and so on). In Axway Composer terminology, the Axway component is referred to as the Synchrony Server. The IntegrationServices workbench is where you design the dynamic part of the software.
This workbench contains a set of objects that you typically configure and modify more than once. In the IntegrationServices workbench, you can: add your Applications and Partners; define communication between Applications, using an underlying Synchrony Server; define communication with Partners Refer to the Composer online documentation or componentspecific documentation for detailed procedures and more information on the different objects you can design. In the case of Integrator, you begin by importing your existing configuration (created during the installation of your Axway components) into Axway Composer. You can then modify and supplement the imported objects before going on to create a configuration container. Refer to the Componentspecific information section for more information.
Creating Deployment containers

Once you have designed the configuration for your environment in Composer, you can use the Deployment Container Creation Wizard to create the deployment container itself. To create the deployment container using the wizard 1. Define the Container attributes: name, version, description and location. 2. Define the list of objects to be placed in the container. 3. Generate the container contents either on the Composer server or on the client. 4. If necessary, manually add configuration items (such as scripts, binaries, exits or documentation) to the container. 5. Generate the container itself by zipping the container directory. For detailed instructions on the wizard, refer to the Composer online documentation.
Deployment Guide 9
2 Using Composer as the design tool
Deployment container structure

A deployment container is a package of standardized folders and files arranged in a predefined hierarchy. Under the root folder, which is effectively the container itself, a sub folder is created for each product. As some products have to manage OSdependent files, under the product subfolder additional subfolders may be created for each target OS. => For Synchrony 4.2. The deployment container contains various files that define the objects included in the container during its creation. In addition, each deployment container contains a number of standard files necessary for deployment. These files are described in the table below. File name and hierarchy [root]/container.xml Description This xml file identifies the container attributes: name, version, id and description. This text file lists the common data used by the component configurations included in the container. This data is shared between the target components runtime environments. This text file contains a unique container audit identifier used to audit deployment and related operations. This xml file describes the target product attributes: product name and version. This xml file lists all externalized environment dependent configuration data (attributes). This file can be edited using the attribute substitution engine.
[root]/common.txt
[root]/ auditId.txt
[root]/[Component]/ component.xml
[root]/[Component]/ attribute.xml
Note
Date formats are standardized for all date attributes described in the container.xml, attributes.xml and component.xml files: yyyy-mmddThh:MM:ss.mmm-Z.
Example of a Deployment container

The following figure illustrates the tree structure of a Deployment container that contains five components: AccountingIntegrator, Composer, Integrator, ProcessManager, and Sentinel.
10 Deployment Guide
Editing the Deployment container
Figure 2. Example of a deployment container directory structure

You can consult the details of the deployment container content in the component.xml file. If required, you can extract the attributes.xml files from the container (one per component) and modify it manually as shown below or using the File update Tool before deploying the container. For more information on the latter, see Specializing using the File Update Tool on page 15.
Example of a component.xml file

Description of the structure of a component.xml file:
Deployment Guide 11
Figure 3. component.xml file
Example of an attributes.xml file

Description of the structure of an attributes.xml file:
12 Deployment Guide
Figure 4. attributes.xml file
Attributes in an attributes.xml file

<Attributes> <Attribute name="synchrony.install.directory" shortDescription="my Synchrony directory" type="string"> <value>D:\axway\synchrony</value> </Attribute> <Attribute shortDescription="my Product directory" type="string"> <pattern>${product_dir}</pattern> <value>D:\axway\synchrony\myProduct</value> </Attribute> </Attributes>
Deployment Guide 13
Modified attributes.xml file

In this example, optional information is added to the attributes.xml file in order to differentiate how several instances of the same attribute (channel.ftp.MainHostname) are processed during deployment. This is achieved by manually adding:
l l
Filter value Filter type category
<Attributes> <Attribute name="channel.ftp.MainHostname" type="string"> <value>myhostname</value> <defaultValue> myhostname</defaultValue> <filterValue>Company.test:ChannelFtp1</filterValue> <FilterType category="FTP">Channel</FilterType> </Attribute> <Attribute name="channel.ftp.MainHostname" type="string"> <value>myhostname</value> <defaultValue>myhostname</defaultValue> <filterValue>Company.test:ChannelFtp2</filterValue> <FilterType category="FTP">Channel</FilterType> </Attribute> <Attribute type="string"> <pattern>${name_4}</pattern> <value>MYHOSTNAME</value> <defaultValue>MYHOSTNAME</defaultValue> <filterValue>Compagny.HOSTS:Integrator/CopilotTask</filterValue> <FilterType>CoreTask</FilterType> </Attribute> </Attributes>
14 Deployment Guide
Specializing using the File Update Tool
This chapter describes how to specialize a deployment containers attributes.xml file containing environmentspecific data, to adapt it to a given target environment.
Basic concept
File Update Tool version 1.0.2 is installed as part of the Axway Infrastructure component and is located in the <Synchrony_Home>/Tools directory. The File Update Tool is a generic tool used to specialize an attributes file with values taken from external files. These external files may be:
l l l
A Synchrony installation file Another attributes file A specific file.
The tool merges data taken from an external file (input file) with an attributes file. An output file is created with updated attributes. This output file can then be used in a container to deploy in the target environment.
Deployment Guide 15
3 Specializing using the File Update Tool
Figure 5. File Update Tool In the figure above, the File Update Tool merges a Synchrony installation file with an attributes file from the container of platform #1, and generates a new attributes file for a container for platform #2.
Launching the tool

The File Update Tool application is launched by a script:
l l
fileupdatetool.bat (for Windows) fileupdatetool.sh (for Unix)
The options are described in the following table. Option -help -version -inputFileTypeList -inputFilePath:<input file path> -inputFileType:<input file type> attributesFilePath:<attributes file path> -outputFilePath:<output file path> Description Display the help Display the application and connector versions Display the available input file types list Set the input file path. The path may be absolute or relative. (Mandatory option) Set the input file type. Default value: attributes
Set the attributes.xml file path. The path is an absolute or relative file path. Default value: ./attributes.xml Set the output file path. The path is an absolute or relative file path. Default value: ./attributes.new.xml Set the properties file path used to initialize the application. Default value: ./conf/settings.txt. Set the merging rules file path. The path may be absolute or relative.
-settingsFilePath:<settings file path> -rulesFilePath:<rules file path>
Settings file
The following table describes the parameter settings managed by the application.
16 Deployment Guide
Log file management
Key
Description
Default value attributes ./attributes.xml
cmd.inputFilePath cmd.inputFileType cmd.attributesFilePath
Absolute or relative input file path Input file type Absolute or relative attributes.xml file path Absolute or relative output file path Absolute or relative merging rules file path Enable audit logs Audit logs output file Language code (en or fr)
cmd.outputFilePath cmd.rulesFilePath
./attributes.new.xml ./rules.txt
log.audit.enable log.audit.outputfile language
false audit.log en
All parameter settings are optional. If parameters are not defined, the default values are used. For command settings, all parameters defined in the application settings file have priority over the parameters from the command line. To use the parameters from the command line, corresponding parameters must not be present in the application settings file.
Log file management

The File Update Tool is logged by Log4J. Log4J is configured in the conf/log4j.properties file. This file defines a standard configuration. The console displays FATAL level messages. This level is used by errors which result in the stopping of the application. These messages are also displayed in a specific log file (log/fatal-fileupdatetool.log). DEBUG level messages are stored in a specific file (log/debug-fileupdatetool.log). This file is managed by a RollingFileAppender to avoid the creation of an oversized log file. The other levels are stored in the fileupdatetool.log file. This is the standard configuration that can be modified according to your requirements.
Specialization process
The specialization process involves two phases:
l l
Standard specialization Specialization using identification rules
These processes are done sequentially.
Deployment Guide 17
Standard specialization
Figure 6. Standard merge In the standard specialization process, the tool compares matching attributes in the input and attributes files. Attributes match if they fulfill the following conditions:
l
If the attribute name is defined in both files (not empty), the names must be equal. Otherwise, if the patterns are defined (not empty), the pattern values must be equal. If an attribute filter is defined in both files, then the filter values must be equal (filter type, category and value).
For each matching attribute, the attribute value of the input file is copied to the attribute value in the attributes file.
18 Deployment Guide
Specialization process
Specialization using identification rules
Figure 7. Specialization using identification rules A specialization using identification rules is different from a standard specialization process. When using identification rules, you select pairs of nonmatching attributes in order to specialize a destination attribute value with a source attribute value. The selection is performed using an identification rule that describes the source attribute value and the destination attribute value. The source selection describes only one attribute of the input file while the destination selection describes a set of attributes of the attributes file. The tool then copies the source attribute value into all the destination attribute values.
Specialization using identification rules with source value concatenation
Deployment Guide 19
Figure 8. Specialization using identification rules with source value concatenation A more complex specialization allows you to select a set of source attributes. The source value is the result of the concatenation of source attributes. In addition, a simple string can be inserted into the concatenation. For example, a JDBC URL can be the result of the concatenation of:
l l l l l l
The string "jdbc:oracle:thin:@" The value MYHOSTNAME1 from input attribute A The string ":" The value 1525 from input attribute B The string ":" The value SYN from input attribute C
The result is jdbc:oracle:thin:@MYHOSTNAME1:1525:SYN.
Identification rules file

If a rules file is defined either in the application settings file or in the command line, the specialization using identification rules are executed. The role of a rule is to describe a selection of one or more source attributes and one or more destination attributes. There are two modes for source attribute selection:
l
Single selection: The rule is composed of only one source attribute. The specialization process uses the value of this attribute. See Standard specialization on page 18. Multiple selections: The rule is composed of several source attributes. The specialization process uses the concatenation of all these attributes. See Specialization using identification rules on page 19.
Rule format
The rule file is an XML file. The format of this XML file is defined in the XSD documentation/rules/rules.xsd. The directory documentation/rules/ contains some examples of rule files). The Rules root element can contain a list of Rule elements.
Rule XML element

From a high level view, a Rule XML element is composed of two elements:
l l
Source Destination
The source and destination elements must describe a selection of a set of attributes. The selection is described in the SelectionAttribute element. An attribute is only selected if all its fields correspond to the SelectionAttribute fields.
SelectionAttribute element
A selection attribute is composed of:
20 Deployment Guide
l l l
A name or a pattern element A filterType element (optional) A flterValue element (optional)
The process is able to select elements from an attributes list that correspond to these elements. Example: <SelectionAttribute> <name>channel.ftp.MainHostName</name> <FilterType category=foo>Channel</FilterType> <filterValue>Entity.test:ChannelFtp2</filterValue> </SelectionAttribute>
Concatenation element
The Source element can contain a SelectionAttribute element or a Concatenation element. The concatenation element is composed of a sequence of elements:
l l
SelectionAttribute string
The selection attribute must represent only one attribute from the input file. The process extracts each attribute representing each selection attribute, and concatenates the selection attributes and the string value to the same sequence as appears in the file.
Unique source attribute

If the source is composed of only one attribute selection, the application ensures that the source attribute selection represents only one source attribute from the input file. If the source is composed of a concatenation, the application ensures that each attribute selection represents only one source attribute from the input file.
Examples
Example of an attributes file: <Attributes> <Attribute name="channel.ftp.MainHostName" type="String"> <value>myhostname</value> <pattern>${MainHostName_0}</pattern> <filterValue>Entity.test:ChannelFtp1</filterValue> <FilterType>Channel</FilterType> </Attribute> <Attribute name="channel.ftp.MainHostName" type="String"> <value>myhostname</value> <pattern>${MainHostName_1}</pattern> <filterValue>Entity.test:ChannelFtp2</filterValue>
Deployment Guide 21
<FilterType>Channel</FilterType> </Attribute> <Attribute name="database" type="String"> <value>jdbc:oracle:thin:@localhost:1521:XIP</value> <pattern>${MainHostName_0}</pattern> <filterValue>Entity.test:ChannelFtp1</filterValue> <FilterType>ChannelDB</FilterType> </Attribute> </Attributes> Both examples below use this attributes file.
Example 1: Simple rule

Input file <Attributes> <Attribute name="hostname" type="String"> <value>MYHOSTNAME1</value> <FilterType></FilterType> </Attribute> <Attribute name="portnumber" type="String"> <value>1525</value> <FilterType></FilterType> </Attribute> <Attribute name="schemaname" type="String"> <value>SYN</value> <FilterType></FilterType> </Attribute> </Attributes> Rules file <?xml version="1.0" encoding="UTF-8"?> <Rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../doc/rules.xsd"> <Rule> <Source> <SelectionAttribute> <name>hostname</name> </SelectionAttribute> </Source> <Destination> <SelectionAttribute> <name>channel.ftp.MainHostName</name> <FilterType>Channel</FilterType>
22 Deployment Guide
<filterValue>Entity.test:ChannelFtp2</filterValue> </SelectionAttribute> </Destination> </Rule> </Rules> Result <Attributes> <Attribute name="channel.ftp.MainHostName" type="String"> <value>myhostname</value> <pattern>${MainHostName_0}</pattern> <filterValue>Entity.test:ChannelFtp1</filterValue> <FilterType>Channel</FilterType> </Attribute> <Attribute name="channel.ftp.MainHostName" type="String"> <pattern>${MainHostName_1}</pattern> <value>MYHOSTNAME1</value> <filterValue>Entity.test:ChannelFtp2</filterValue> <FilterType>Channel</FilterType> </Attribute> <Attribute name="database" type="String"> <value>jdbc:oracle:thin:@localhost:1521:XIP</value> <pattern>${MainHostName_0}</pattern> <filterValue>Entity.test:ChannelFtp1</filterValue> <FilterType>ChannelDB</FilterType> </Attribute> </Attributes> The selected attribute is only the one called channel.ftp.MainHostName, the filter type is Channel and the filter value is Entity.test:ChannelFtp2.
Example 2: Concatenation rule

Input file <Attributes> <Attribute name="hostname" type="String"> <value>MYHOSTNAME1</value> <FilterType></FilterType> </Attribute> <Attribute name="portnumber" type="String"> <value>1525</value> <FilterType></FilterType> </Attribute> <Attribute name="schemaname" type="String">
Deployment Guide 23
<value>SYN</value> <FilterType></FilterType> </Attribute> </Attributes> Rules file <?xml version="1.0" encoding="UTF-8"?> <Rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../doc/rules.xsd"> <Rule> <Source> <Concatenation> <string>jdbc:oracle:thin:@</string> <SelectionAttribute> <name>hostname</name> </SelectionAttribute> <string>:</string> <SelectionAttribute> <name>portnumber</name> </SelectionAttribute> <string>:</string> <SelectionAttribute> <name>schemaname</name> </SelectionAttribute> </Concatenation> </Source> <Destination> <SelectionAttribute> <name>database</name> <FilterType>ChannelDB</FilterType> <filterValue>Entity.test:ChannelFtp1</filterValue> </SelectionAttribute> </Destination> </Rule> </Rules> Result <Attributes> <Attribute name="channel.ftp.MainHostName" type="String"> <value>myhostname</value> <pattern>${MainHostName_0}</pattern> <filterValue>Entity.test:ChannelFtp1</filterValue> <FilterType>Channel</FilterType>
24 Deployment Guide
</Attribute> <Attribute name="channel.ftp.MainHostName" type="String"> <pattern>${MainHostName_1}</pattern> <value>MYHOSTNAME1</value> <filterValue>Entity.test:ChannelFtp2</filterValue> <FilterType>Channel</FilterType> </Attribute> <Attribute name="database" type="String"> <pattern>${MainHostName_0}</pattern> <value>jdbc:oracle:thin:@MYHOSTNAME1:1525:SYN</value> <filterValue>Entity.test:ChannelFtp1</filterValue> <FilterType>ChannelDB</FilterType> </Attribute> </Attributes> The selected destination attribute is only the one named database, the filter type ChannelDB and the filterValue Entity.test:ChannelFtp1.
Wildcards
In order to simplify the rules file, the fields of a destination selection Attribute can be defined by an asterisk (*) wildcard. This wildcard is used to substitute a zero or more characters. The asterisk wildcard only manages the selection of the destination attribute.
Example 1
<Rule> <Source> <SelectionAttribute> <name>hostnamePRD</name> </SelectionAttribute> </Source> <Destination> <SelectionAttribute> <name>hostname*</pattern> </SelectionAttribute> </Destination> </Rule> This destination selection attribute selects all attributes in the attributes file that have a name starting with hostname.
Example 2
<Rule> <Source> <SelectionAttribute>
Deployment Guide 25
<name>hostnamePRD</name> </SelectionAttribute> </Source> <Destination> <SelectionAttribute> <pattern>${MainHostName_*}</pattern> <FilterType>Channel</FilterType> <filterValue>Entity.test:ChannelFtp*</filterValue> </SelectionAttribute> </Destination> </Rule> This destination selection attribute selects all attributes in the attributes file that have a pattern starting with MainHostName_, a FilterTypes type equal to Channel and a filterValue starting with Entity.test:ChannelFtp*.
26 Deployment Guide
Deploying containers
This chapter provides the information necessary to deploy containers using an external deployment tool.
Overview
When you have created a deployment container with the necessary objects and configuration, you must deploy this information to the target environment using the deployment tool. All Axway components that support deployment also comply with a list of server commands related to deployment that can be used in conjunction with a third party deployment tool. The deployment of a deployment container involves the following steps:
l
Import the deployment container to the runtime environment.

l
The contents of the container for the target component are retrieved: object configurations, container.xml, attributes.xml, component.xml. The compatibility and integrity of the configuration files is checked. The configuration files are updated using the values in the attributes.xml file. The target component repository is updated.
l l l l l
The list of the imported containers and their details are displayed Throughout the steps above, the import and cancel operations are audited.
Server commands
All Synchrony components that support deployment also comply with a list of server commands that can be used during the deployment operation. The main command is deployment. Note For Integrator, Sentinel, and ProcessManager do not use these commands as each component has their own. For details, refer to their dedicated chapters in this guide.
Import
Description Imports a deployment container. Set either the root folder path of the container or the container identifier if a default container directory is defined for product in the command line.
Deployment Guide 27
4 Deploying containers
Command
-import [-update] [-ignoredate] [] {-path <path to container> | -id <container identifier>} [-attributesFile <path to attributes file>] -path <path to container>: Root folder path of the container to import -id <container identifier>: Identifier (<Name +''+Version>) of container to import -attributesFile <path to attributes file>: You can use an external attributes file during import. If user specifies this command, then the attribute file delivered in the container is not taken into account: the component uses the file specified in the command line instead.
Parameters
Remove
Description Command Parameters This command allows you to remove a container. -remove <container identifier> (<Name +'-'+Version>) N/A
List
Description This command allows you to display all containers or objects imported and present in the repository. -list {-containers | -objects} -containers: display the list of containers -objects: display the list of objects
Command Parameters
Detail
Description This command allows you to display the details of an imported container: list of objects. -detail <container identifier> (<Name +'-'+Version>) N/A
Command Parameters
Help
Description Command This command allows you to display the help for the list of commands. -help
28 Deployment Guide
Server commands
Parameters
N/A
Clean
Description This command allows you to remove all imported containers present in the repository. -clean N/A
Command Parameters
Export
Description This command allows you to export the deployment container present in the design repository to the server. -export <destination directory> [-name <container name>] [version <container version>] [-description <container description>] [-objectsList <objects list to export>] -name: name of the container to be exported. -version: version of the container to be exported. -description: short description of the container to be exported. -objectsList: list of the objects to be exported in the container. Mandatory for Composer
Command
Parameters
Deployment Guide 29
4 Deploying containers
30 Deployment Guide
Deploying to Integrator
This section provides deploymentrelated information for Axway Integrator.
When deploying to Integrator Servers, you perform different tasks than for other components.
l l
Install three Synchrony platform environments: design, preproduction, production. In the Composer Topography workbench, create an Axway Server object to represent an Integrator Server. Make sure all the MBC objects on the Integrator Server have been registered correctly in Copilot. The deployment operation does not deploy or register MBCs. You must do this manually. For more information, refer to the Integrator Enabler online documentation. Import Environment #1 (development environment with all of the Core Tasks and MBCs that reside on the Integrator Server instance) to Composer as described in the procedure below. Note: In connected mode, use the importObjectSet command to import the configuration directly from the Integrator Server of the development environment. In connected mode, you do not need to export the object set to a deployment container file. When all configuration design tasks are completed in Composer, export the object set to a deployment container and deploy to preproduction and production.
About the deployment lifecyle

To understand the how Composer and the Integrator Enabler interact with Integrator Servers to deploy an integration from development to preproduction to production, see the diagram below.
Deployment Guide 31
5 Deploying to Integrator
Figure 9. A simplified view of the deployment lifecycle for an integration. See the table below for an explanation of the steps.
Deployment lifecycle process

The following table summarizes the steps in the deployment lifecycle as well as the Composer and Integrator commands involved. To deploy to Development Perform these steps 1. In Composer, use Send to Server/Remove from Server to deploy/modify the IntegrationTasks. If the integration loads objects dynamically, run another Send to Server operation to deploy these dynamic objects separely.
32 Deployment Guide
Connect or disconnect Composer
To deploy to Pre production
Perform these steps Before your first deployment to a preproduction Integrator Server, you must first establish a link between this server and the Composer instance used in development. a. On the preproduction Integrator Server, run Integrator deployment exportObjectSet. This generates the file that defines the Integrator Server configuration for that particular server machine. For more on this command, -exportObjectSet on page 37. b. In the Composer Topography Workbench, rightclick the Integrator Server, then select Advanced Actions > Update from file. This step establishes the link. 2. In Composer, generate a deployment container for the IntegrationTask. If updating, you must include any dependant objects. For more about updating, Updating and dependant objects on page 41. 3. On the preproduction Integrator Server, disconnect from the Composer, then run Integrator deployment -import <path to container>.
Production
4. Create an attribute file that defines the machine specific settings for the production Integrator Server. You can use the File Update Tool to create attribute files. For more information, see the Synchrony Deployment Guide. 5. On the production Integrator Server, run Integrator deployment -import <path_to_ container> -attributesFile <path_to_attributes_file>.
Connect or disconnect Composer

You can deploy objects either in connected mode, or disconnected mode. The connection mode to use depends on the server environment you are deploying to.
Deployment Guide 33
Typically, you deploy to a development environment from Composer . You must be in connected to Composer to do this. This is known as a connected deployment. On the other hand, in a preproduction or production environment, typically you use server commands to import deployment Containers to the Integrator Server. You must be disconnected from Composer to do this. This is known as a disconnected deployment.
The servermode command prepares the Integrator Server for deployment by cleaning the Integrator Server repository and then either connecting to or disconnecting from its corresponding Axway Composer Server.
Linking an Integrator Server to Composer

Before you can disconnect or connect an Integrator Server instance and a Composer instance , you must establish a link between them. 1. From the Integrator Server, export the server configuration by running the Integrator deployment -exportObjectSet command. 2. In Composer Topography Workbench, rightclick the Integrator Server then select Advanced Actions > Update from file and import the ObjectSet. After doing these steps, this Integrator Server will only accept imports from this particular Composer instance (but will accept Containers from any Mapping Services instance).
Servermode commands
Note To use the following commands with Integrator 3.5 or earlier : 1. Set environment variables by going to $CORE_LOCAL/bin (UNIX) or %CORE_ LOCAL%/bin (WIN) and running CORE_SETUP. 2. Run the commands described below, replacing Integrator with Launcher.
-connectedBroadcast
Description Cleans Integrator Server repository then connects to the linked Composer Server. Integrator servermode -connectedBroadcast
Syntax
-disconnectedBroadcast
Description Cleans Integrator Server repository then disconnects from the linked Composer Server. Integrator servermode -disconnectedBroadcast
Syntax
Deploying Containers
The deployment commands enable you to import Containers directly from an Integrator Server, or view what has already been deployed.
34 Deployment Guide
Note
To use the following commands with Integrator 3.5 or earlier : 1. Set environment variables by going to $CORE_LOCAL/bin (UNIX) or %CORE_ LOCAL%/bin (WIN) and running CORE_SETUP. 2. Run the commands described below, replacing Integrator with Launcher.
Prerequisites
Before you can use any deployment command, you must disconnect the Integrator Server from Composer by using Integrator servermode -disconnectedBroadcast .
Deployment commands
-import
Description Syntax Imports a container to Integrator Server. Integrator -import <path_to_container> [-update] [-ignoreDate] [-ignoreServerDate] [attributesFile <attribute_file_path>] [ignoreMissingMfcs] Where: [-update]: Import a new version of alreadydeployed object. [-ignoreDate]: Does not compare dates in update mode. [-ignoreServerDate]: Does not compare dates when importing modified Axway Server object. [-attributesFile <path_to_attributes_file>]: Modifies target server with these attributes. [-ignoreMissingMfcs]: Does not return an error if the MFCs are not on target server. Use when deploying to production. Examples Integrator deployment import C:\Axway\Synchrony\Integrator\Sample -update Result: Imports the C:\Axway\Synchrony\Integrator\Sample\Container.xml file into the Integrator Server repository, and updates any dependant objects in the repository where the modification date is earlier than that for the object in the container. Integrator deployment import C:\Axway\Synchrony\Integrator\Sample update ignoreDate Result Imports the Sample_container\Container.xml file into the Integrator Server repository, updates any dependant objects in the repository regardless of modification date.
Deployment Guide 35
Prevent runtime errors with the -ignoreMissingMfcs option

Caution Only use this option when importing to a different Integrator Server than the one defined in the container. Deployment containers always include the Axway Server object, which provides configuration information for the target Integrator Server. When you deploy to production, often the Axway Server in the container does not exactly match the production configuration. To prevent runtime errors on the production Integrator Server, do the following in Composer before importing:
l
On the target Integration Server object, register the MFCs used by the container's IntegrationTask(s). or
Verify that the MFCs defined on the Axway Server object in the container are not used by the IntegrationTask(s) in the container.
Adjust server configuration with the -attributesFile option

A container was designed for a preproduction server, it has been validated and now needs to be deployed on the production server, which is a clone except for some parameters like hostname, ports number, All these parameters can be defined in the attributes file and replaced automatically during import. You can create an attribute file using the File Update Tool. For more information, see the Synchrony Deployment Guide.
-clean
Caution Use this command only when instructed to by Axway Technical Support. Description Syntax Special Notes Cleans the repository of Integrator Server Integrator deployment -clean The -clean command removes:
l l l
all deployed containers all coretasks resets the runtime server to the original installation configuration (For example, 1 HME, 1 PE and so forth). registered MFCs installed patches and service packs
but keeps:
l l
36 Deployment Guide
-remove
Description Syntax removes a container from Integrator Server Integrator deployment -remove <audit_ID> [recursive] Where: <audit_ID>: alphanumeric ID for the container. To retrieve this ID, use -list -containers, or see AuditID.txt in Container folder. [-recursive]: removes any other container with objects that depend on objects in the container being removed. Example Integrator deployment -remove d2c310e8-90df-11dfbbee-000c2976c7df -recursive Result: Removes the container, plus any other containers with objects that depend on objects in the d2c310e890df 11dfbbee000c2976c7df container. Special Notes You must use the recursive option when removing containers that were deployed or updated using the update option. For more information, see Example 3: Remove Container that has dependant Containers on page 45.
-exportObjectSet
Description Exports the server configuration for the Integrator Server. Integrator deployment -exportObjectSet <destination_directory> Where: <destination_directory>: Container directory Example Integrator deployment -exportObjectSet C:\Axway\Synchrony\Integrator\Containers\Updates Result: Creates Export.xml in C:\Axway\Synchrony\Integrator\Containers\Updates Special Notes Use this file to update objects with destination's Integrator Server configuration before creating a deployment container in Composer.
Syntax
Deployment Guide 37
-containerContent
Description Syntax Display container content before deployment. Integrator deployment -containerContent <containerDirectory> Integrator deployment -constrainer C:\Axway\Synchrony\Integrator\Containers Result: Displays list of objects in the container. Special Notes Does not work for containers that have already been imported. Instead, use Integrator deployment detail.
Example
-detail
Description Syntax Displays container content after deployment. Integrator deployment -detail <audit_ID> Where: <audit_ID>: alphanumeric ID for the container. To retrieve, use -list -containers or see AuditID.txt in the Container folder.
-list -containers
Description Syntax Displays Audit ID for all the deployed containers. Integrator deployment -list -containers
-list -objects
Description Syntax Displays Audit ID for all repository content. Integrator deployment -list -objects
38 Deployment Guide
Which objects can you deploy, and when?
-list -mapstages
Description Syntax Displays Audit ID for all repository MapStages. Integrator deployment -list -mapstages
Which objects can you deploy, and when?

When creating a deployment Container, there are only certain objects that can be explicitly added to the Container. Other objects are included implicitly when their parent (or their parent's parent) is added. The checked objects in the diagram below indicate objects that you explicitly add to a deployment Containers, either as a standalone object or together with other objects.
Figure 10. Diagram showing which Integrator objects you add to a Container and which you cannot. The table below explains the under what circumstances you should deploy these objects to theIntegrator Server. For the objects not listed in this table, you cannot create a container or explicltly include them in any container; they are included automatically when you select the object that references them. For example, if you selected a MapStage when creating a Container, it would also include the associated MapBrokers, BusinessDocuments, Tables, Variables, and CustomFunctions.
Deployment Guide 39
Deployable object Axway Server
When to include in a Container To manage the configuration of your server independent of any functional configuration.
What it does
An Axway Server describes the server configuration (such as the necessary CommAdapters and Core Tasks). Deploying an Axway Server object therefore adds the CommAdapters and Core Tasks that were not already on the server. Removing CommAdapters and CoreTasks
l
If you remove CommAdapters and CoreTasks from an Axway Server object in Composer, deploying this Axway Server object will not delete those CommAdapters and CoreTasks on the physical server. This ensures existing functional containers continue to run successfully. For the same reasons, removing this object (either by removing it as a single object in a container or as one of several objects in a container) does not delete the CommAdapters or the Core Tasks. To remove Core Tasks and CommAdapters, use the Integrator optimizeServer command
Integration Task
For a typical deployment, this is the only object you need to deploy. To deploy dynamicallyloading MapStages only.
Selecting an IntegrationTasks for a container means all its associated objects (Integration Process , MapStages, Axway Server and Channels) are included as well. Static Map-Stages If your integration loads MapStages statically, then they are automatically included in the IntegrationTask container and do not need to be selected explicitly. To update, we recommend redeploying the associated IntegrationTask. Dynamic Map-Stages For dynamicallyloaded MapStages, you can either add the MapStages into the Integration Task container or deploy them separately.
l
MapStage
If you consider that the MapStages belong to the same project than the IntegrationTask, you would probably include them.
40 Deployment Guide
Updating and dependant objects
Deployable object
When to include in a Container
What it does
If you consider them as separate developments (maybe other people are doing them), you would create a specific container for each Map Stage. Doing so, you have much more flexibility for updates and especially removal of containers. The drawback is that you will have many more containers to manage.
To update, deploy the updated MapStage as a separate container. Channel To dynamically override Channel attributes at runtime, you may want to deploy new Channels independently. This implies that the right Channel is called (eg the override attributes are set properly). While you can deploy Channels as independent Containers, it is not mandatory: Channels are linked to the IntegrationTask and so are automatically included in the IntegrationTask container. That being said, if an update to a Channel's configuration has no real impact on the IntegrationTask, you can deploy the updated Channel in an independent container. Nonetheless, we still recommended redeploying the complete IntegrationTask for such cases.
Document Identifier
You must always explicitly add DocumentIdentifiers to a Container, either as an independent Container, or as an addition to another container. Best practice: add themwithin an IntegrationTask container.
DocumentIdentifiers are dynamic objects; they are not linked to the IntegrationProcess that uses them. To add new DocumentIdentifiers intended for an existing IntegrationProcess that doesn't need modifying, you can deploy them as an independent container. They will be taken into consideration, as long as they are called (thats a matter of setting the attributes properly). To update a DocumentIdentifier, you can deploy it as an independent container since there is no impact on the IntegrationTask.
Updating and dependant objects

After your initial deployment to an Integrator Server, you will need to update your integrations by importing modified versions of previouslydeployed objects.
Deployment Guide 41
About Integrator versioning

When importing an object , Integrator checks the following:
l l
Repository name, which is made up of the qualifiedname + Audit ID Modify date
As a safeguard, the Integrator Server does not allow a simple import when there is a version conflict. If you try to import a Container that includes an object with the same repository name as an object already on the Integrator Server, the import will fail, unless you add the -update option to the end of the command. Note A repository name in the Integrator Server consists of the object name as it appears in Composer (Company Name.Folder Name.Object Name), plus the Audit ID. The Audit ID represents the folder in Composer, the kind of object (Business Document, MapStage, Table, Variable, and so forth), and then the object type for MapBroker and BusinessDocuments. To retrieve the repository name, use Integrator deployment -list -objects.
About the -update option

When another object with the same repository name already exists in the Integrator Server repository, you must include the -update option to your -import command: Integrator deployment -import <path_to_container> -update If the modify date for the object in the deployment container is more recent than the modify date of the object with the same repository name already residing in the Integrator Server repository, this repository object will be updated to the version of the object in the deployment container.
Figure 11. Integrator will not allow the import of Container2, because there is a version conflict: Container1 has an earlier version of the same object.
42 Deployment Guide
Deployment examples
Figure 12. To successfully import Container2 and update the existing Container1, append the -update option to the import command.
About Container and object dependancy

The Container that requires the -update option for importing is known as a dependant Container. The object in the dependant Container that is causing the version conflict is known as the dependant object.
Deployment examples
These examples, using the Containers shown below, explain how object dependency determines which options you must use with the Integrator deployment -import command.
Figure 13. Container1 and Container2 include the same Map-Broker Map-Broker err. Container1 and Container3 both include Document-Identifier A, but Container3 includes a more recent version. The examples that follow are all based on the Containers shown above.
Example 1: First-time deployment

The Integrator Server is empty.
Deployment Guide 43
Objective: Deploy Container1. Command: Integrator deployment -import Container1 Result: Successful deployment, Container1 now resides on the Integrator Server.
Example 2: Deploy a dependant Container

Container1 now resides on the Integrator Server. Objective: Deploy Container2, which includes a MapBroker that is also in Container1. Incorrect command: Integrator deployment -import Container2 Result: Deployment fails. Container2 includes MapBroker err, which was already deployed in Container1. Map-Broker err is a dependant object.
Correct command: Integrator deployment -import Container2 update
Result: Container2 now added to the Integrator Server. Container2 is dependant on Container1.
44 Deployment Guide
Deployment examples
Example 3: Remove Container that has dependant Containers

Container1 and the dependent Container2 both reside on the Integrator Server. Objective: Remove Container1 from the Integrator Server. Incorrect command: Integrator deployment -remove {Container1 AuditID} Result: Remove fails. The Integrator Server also includes Container2, which depends on Container1.
Note
To obtain Audit ID, use the Integrator deployment -list container command
Correct command: Integrator deployment -remove {Container1 AuditID} -recursive
Result: Container1 removed from the Integrator Server. Container2 removed from the Integrator Server.
Example 4: Remove Container without dependant Containers

Container1 and the dependent Container2 both reside on the Integrator Server. Objective: Remove Container2 from the Integrator Server. Command Integrator deployment -remove {Container2 AuditID} Result: Remove successful. You do not need the -recursive option in this example because no other Containers depend on objects in Container2.
Deployment Guide 45
Example 5: Deploy dependant Container with newer version of dependant object

Container1 already resides on the Integrator Server. Objective: Deploy Container3. Command Integrator deployment -import Container3 -update Result: Container3 is added to the Integrator Server. Document-Identifier A in Container1 is updated to Document-Identifier A v.2.
Example 6: Update dependant object used by other objects

Container1 and Container2 already reside on the server. Objective: Update Map-Broker err , which is common to Container1 and Container2.
l
Updating this MapBroker means also updating Map-Stage A and Map-Stage B to use Map-Broker err v2. To deploy the new versions of the MapStages, you must deploy new versions of Container1 and Container2. Result: First command replaces Container1 with Container1 v2, and updates the dependant object in Container2 to Map-Broker err v2. However, since Map-Broker err v2 in Container2 requires Map-Stage B v2, this first command is not enough. The second command replaces the existing
Commands: Integrator deployment -import Container1 update Integrator deployment -import Container2 -update
46 Deployment Guide
Rolling back to earlier versions
Container2 with Container2 v2 which updates the MapStage to Map-Stage B v2.
Rolling back to earlier versions

The examples here describe how you can rollback to earlier versions of Containers or server configurations, by using the -IgnoreDate or -IgnoreServerDate options when updating.
Example: Rolling back to an earlier Container

To deploy a set of objects in a Container (ContainerA, version 1, date 1), you would use this command: Integrator deployment import ContainerA Afterwards, you modify some objects and then create a new version of the Container (ContainerA ,version 2, date 2). Since this Container was already deployed, you must use the -update option. Since the date is later than that of the Container currently residing on the Integrator Server, this Container meets Integrator's default validation criteria. Integrator deployment import ContainerA update After testing the new behavior, however, it is not what you expected. You decide to rollback by deploying the first version that you had previously saved (ContainerA, version 1, date 1). Again, since you are deploying a Container that was deployed earlier, you will need the update option. The key difference now is the modify date for this Container predates the modify date of the Container currently residing on the server. Therefore, for Integrator to accept this import, you must add the -ignoreDate option to the end of the command: Integrator deployment import ContainerA update -ignoredate
Deployment Guide 47
Example: Rolling back to an earlier server configuration

To deploy a set of objects in a Container (ContainerA, ServerConf1), you would use the following command: Integrator deployment import ContainerA Afterwards, you create a new set of objects in a second Container (ContainerB, ServerConf1). You do NOT deploy this container right away, but keep it for later. Meanwhile, you modify the Server configuration, and the objects from ContainerA. This means you need to create a new version of ContainerA. Since Containers always include server configuration, the server modification will be included in the new Container (ContainerA ,version 2, Serverconf2). Because you are deploying a Container that was previously deployed, you must use the -update option. Since the date is later than that of the Container currently residing on the Integrator Server, this Container meets the default validation criteria. Integrator deployment import ContainerA update As a result, the objects in ContainerA are updated with your modifications, as is the server configuration. You now deploy ContainerB. The server configuration is older than the one on the Integrator Server so you need the -ignoreServerDate option. Integrator deployment import ContainerB ignoreServerDate This ensures that you can import the objects in ContainerB, without updating the server configuration (unless there are new configurations needed for the objects in this Container).
Managing Integrator deployment packages remotely

Axway provides a client batch importer tool that you use to execute launcher commands on an Integrator Server from a remote machine. Typically, the batch command is used to automate configurations from a central location and is launched by a script. It is useful to link the batch command to PassPort to retrieve access permission for the Integrator Server(s) on which you wish to run the launcher commands. If Integrator Server is installed using PassPort authentication and authorization management, you must supply the client batch importer command with a valid PassPort username and password. You can either provide these values during the importer tool installation in order to record them in the local system, or enter them directly in the batch command using the user <myuser> password <mypassword> parameters.
Installing the batch importer tool

To use the batch commands from a remote machine, you first install the client batch importer tool: 1. Using the Synchrony Installation DVD, install the client batch importer on a selected machine. 2. During the installation process, enter:
48 Deployment Guide
Importing to a server with a different OS
The name of the Integrator Server and access port that you want to configure remotely. A user name and password (optional).
Using the batch importer tool

1. To use the batch importer tool, navigate to the installation directory of the importer tool and launch a batch session. A console screen and system prompt are displayed. 2. At the system prompt, enter any launcher command. In the command you must add the name of the host and access port of the Integrator Server machine. For example: Integrator deployment import c:\container1 -host<my_integrator_host> port <my_integrator_port> -host and -port are optional if they are configured in install. You can override the host/port values if you want to connect to another Integrator Server. 3. By default there is no user/password to provide if Integrator does not run using PassPort authentication and authorization management. If you do use PassPort services, and you entered a username and password during the installation, the batch importer tool retrieves these values from the stored file on the local machine and uses it for authentication with the Integrator Server. 4. After the optional user authentication procedure, the command is executed on the Integrator Server.
Importing to a server with a different OS

When importing a container originally designed for a given OS to another type of OS, for example when you want to import a container originally designed for a Windows environment to a UNIX environment, on the target OS server:
l l
Run the clean server command. Check that the value and format of all related attributes match the parameters defined on the target server. If you require any C CustomFunctions, check that they are installed. If any MBCs use external libraries, check that these libraries are installed and configured. If the container uses external products that require libraries, check that they are installed and configured.
l l
Consecutive imports
When you import a container originally designed for a given OS to another type of OS, you run the clean server command beforehand. If you then want to import a second container that contains a different Synchrony Server, you must run the clean server command again to avoid any conflict between the CoreTask descriptions. Therefore, you cannot import several containers originally designed for different OS to the same target server. Note This limitation does not concern containers that only contain MapStages.
Deployment Guide 49
Integrator attribute names

Server.agentHost CopilotTask.Name SystemPrimaryMachineTask.Name CommNetwork.ExternalCommAdapterPort CommNetwork.ExternalCommNetworkHostName Channel.MainHostname Channel.Port Channel.Account Channel.Pwd Channel.ScriptSend Channel.Script CommAdapter.FloatingHost CommAdapter.FloatingPort Channel.User Channel.Password Channel.DatabaseName Channel.Jdbc.Port Channel.SystemNumber Channel.Destination Channel.ProgramId Channel.GatewayHost Channel.GatewayService Channel.Client Channel.Language Channel.User Channel.ImplementationClass Channel.ConnectionFactoryName Channel.Jms.Destination CommAdapter.BackupHost CommAdapter.BackupPort CommAdapter.MessageFeed.Port CommAdapter.CommPoint.User CommAdapter.CommPoint.Password CommAdapter.HttpsPort CommAdapter.CertificateFile CommAdapter.PrivateKeyFile CommAdapter.PrivateKeyPwd CommAdapter.CypherString Channel.DialogProgram Channel.DialogProgram Channel.CertificateFile Channel.PrivateKeyFile Channel.PrivateKeyPwd
50 Deployment Guide
Integrator attribute names
Channel.CypherString Channel.Url Channel.SMTPPort Channel.POP3Port CommAdapter.User CommAdapter.Password CommAdapter.Port CommAdapter.DataExchangeDirectory
Deployment Guide 51
52 Deployment Guide
Deploying to ProcessManager
This section provides deploymentrelated information for Axway ProcessManager.
Architecture
The XML import/export is integrated as part of the Modeler and its code it not used anymore. It is replaced by a new export XML file, Export Deployment as displayed in the figure below.
Figure 14. ProcessManager Deployment method
Functionalities
Functionalities are the same as those expected for Synchrony Deployment. You start the commands in the admin console (xpmAdm). The disconnected import is replaced by the deployment import command.
Deployment Guide 53
6 Deploying to ProcessManager
Synchrony Deployment -import [update] [RD:ignoredate] [RD:...] {-path <path to container> | -id <container identifier>} [RD:-attributesFile <path to attributes file>] -list {-containers | objects} -clean -remove [RD:restorepreviousstate] <container identifier> -detail <container identifier> -help
ProcessManager Deployment import path <path_to_container> [attributesFiles <path_to_ attributes_file>] [-update]
list {containers|objects [<ObjectType>]} clean remove <Container identifier>
detail <Container identifier>
help
The Export Deployment Container

ProcessManager has to manage configuration files with attributes.
Container overview
The configuration container is structured as follows: BP_checked_1_e007af96_7f1a_11dd_8f41_00188b085a39
Common.txt AuditId.txt Container.xml Prerequisites.xml Variables.xml
Composer Attributes.xml Component.xml ContainerObjectsDependencies.xml Exportfile.xml Logfile.xml ProcessManager Attributes.xml Component.xml
54 Deployment Guide
Server.xml Channels.xml MonitoringTemplates.xml BdocXXX.xml BprocessXXX.xml Services.xml CustomFunctions.xml
There is one file for every object. For example, in BusinessDocument_XXX.xml, X represents the name of the businessDocument.
Attributes.xml
The following table lists some of the ProcessManager attributes. Object Type Attribute name hostname Pattern
Host TCPCommNetwork
TCPCommNetwork
hostname
Axway Server
Engine (x)
database name driver type database port database host custom url database user database password
engine_ dbname engine_ dbtype engine_ dbport engine_ dbhost engine_curl
engine_ dbuser engine_ dbpassword
Deployment Guide 55
Object
Type
Attribute name user
Pattern
Server CommPoint
ProcessManager handling (x)
pmHandling_ user pmHandling_ pwd pmTrigInt_ user pmTrigInt_ pwd pmBRules_ repotype pmBRules_ url pmBRules_ user pmBRules_ pwd pmJdbc_ drivertype pmJdbc_ dburl pmJdbc_ dbuser pmJdbc_ dbpwd pmWfw_ drivertype pmWfw_ dbname pmWfw_port pmWfw_ dbuser pmWfw_dbpwd
password
ProcessManager Trigering by internal queuer (x)
user
password
Application
ProcessManager Business Rules Repository (x)
repository type url
user
password
ProcessManager JDBC (x)
driver type database url user
pwd
ProcessManager Workflow (x)
driver type database name port user
password
56 Deployment Guide
In the Type column, (x) indicates that there can be several occurrences. For each Pattern, x should be replaced by the occurrence number. Example: <?xml version="1.0" encoding="UTF-8" ?> <Attributes xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:noNamespaceSchemaLocation="Attributes.xsd"> <Attribute name="Business Rules repository type" type="String"> <filterValue>channelrules</filterValue> <FilterType>ProcessManager Business Rules CommAdapter</FilterType> <pattern>${pmBRules_repotype_0}</pattern> <defaultValue>Drools</defaultValue> <value>Drools</value> </Attribute>
Export Files
For every export file deployed, a schema is done for each one (server.xml and channels.xml). Only server.xml can have attribute values.
Auditing activities
All deployment commands executed in the admin console are logged in logs/manager.log files. The operation details are logged in the new file logs/deployment.log.
Using Sentinel
Each operation can be sent to Sentinel. For this an existing ProcessManager monitoring mechanism will be used, that is putting monitor messages in a MONITOR queue that is read by the Monitoring Agent. This monitoring is optional. Configuration of the audit type is done in PM_ Server/conf/XPM_params.properties. In this file there are three sentinel parameters: # Sentinel connection definition TRKIPADDR TRKIPPORT Audit.auditDeploymentCommands = false Deployment monitoring will be activated only if Audit.auditDeploymentCommands is true. Default value is false
Deployment Guide 57
58 Deployment Guide
Deploying to Sentinel
This section provides deploymentrelated information for Axway Sentinel.
Deployment commands
Sentinel complies with the standard list of server commands. Usage: updates repository. Command -import<-path path_to_ container> -clean Description Imports a container
Removes all imported containers present in the repository Displays the path of the configuration file
-conf <configFileName> -detail <container identifier> -list <-containers|objects> -remove <container identifier> -unlockImportMode
Displays details of an imported container: list of objects
Displays all containers or objects imported and present in the repository Removes a specified container from the repository
Unlocks import mode
Sentinel attributes management

To manage Sentinel attributes, use the Attributes.xml file that is included in each generated container, located at <path to Container>\Sentinel. Modifiable attributes in the Attributes.xml file:
l
SQL Datasource: Manual URL Generation

l l
SqlDataSource.DatabaseConnection.host SqlDataSource.DatabaseConnection.port
SQL Datasource: Assisted URL Generation

l
SqlDataSource.DatabaseConnection.url
Recommendation: Browser and Custom Type

l l
Recommendation.Editor.value Recommendation.FilePath.value
Deployment Guide 59
7 Deploying to Sentinel
Probe: ScanFile
l l
Probe.ScanFile.ProbeStringAttribute.filePath Probe.ScanFile.ProbeExpression.fileName
Probe: ExistenceFile
l l
Probe.ExistenceFile.ProbeStringAttribute.filePath Probe.ExistenceFile.ProbeExpression.fileName
Probe: JDBC
l
Probe.JDBC.ProbeStringAttribute.Url
Probe: Terminal
l l
Probe.Terminal.Connection.host Probe.Terminal.Connection.port
60 Deployment Guide
Auditing deployment
This chapter describes how to audit the deployment operation using Axway Sentinel.
Tracked objects
Broadcast and deployment activity in Composer can be audited using the following Axway Sentinel Tracked Objects:
l l
ServerLog: used to audit operations and their result. Deployment: used to provide details on configurations involved in container operations. As auditing container details can generate large volumes of data, this audit type is optional.
ServerLog TO attributes
The following information is audited in the ServerLog Tracked Object: Attribute name ProductName AuditApplicationID Description
Type of the sender application, for example Composer Server Identifier of the sender application: depends on the application type Group of the audited action Unique ID of the user session Identifier of the user that performed the audited action Action name Type of object involved in the audited action Name of the object involved in the audited action Status of the action [Success/Failure] Details of the action (for example, 'export container' or 'import container')
AuditGroup AuditSessionID AuditUser AuditAction AuditObjectType AuditObjectName AuditStatus AuditDetail
Deployment TO attributes
The following information is audited in the Deployment Tracked Object:
Deployment Guide 61
8 Auditing deployment
Attribute name ProductName
Description Type of the sender application, for example Composer Server Identifier of the user that performed the audited action Deployment command Type of object involved in the deployment command Name of the object involved in the deployment command Validity start date for AccountingIntegrator objects only Status of the action [Success/Failure] Details of the action performed by the runtime part of the product (Add, Update, Skip, Delete) during import or remove operations Identifier of the sender application: depends on the application type System attribute used to manage link with ServerLog TO
AuditDeployUser AuditDeployAction AuditDeployObjectType AuditDeployObjectName AuditDeployObjectDate AuditDeployStatus AuditDeployDetail
AuditApplicationID
CycleID
Activating deployment monitoring for Composer

The parameters used to configure the Audit function in Composer are located in the #Audit section of the composer.properties file. Refer to the Configuring the Audit function section of the Composer Operating Guide for information on monitoring operations.
62 Deployment Guide
Using Composer for maintenance
This chapter describes how to make corrections to a configuration that has already been deployed.
In connected mode
When a communication link exists between Composer and the component server or Broadcast Agent, you can use the Remove from Server and the Send to Server commands to update deployed objects. For more information, see the Composer online documentation.
In disconnected mode
If the link between Composer and the component server or Broadcast Agent In disconnected mode does not exist, do one of the following:
l
Composer to Server
l
Update the object(s) requiring corrections in the same Composer environment used to originally create the Deployment container. Make your corrections to the object(s) in Composer. You can then regenerate a new Deployment container including the corrected object(s) and deploy it on the Synchrony server.
l l
Server to Composer
l
Import the deployed deployment container with the object(s) requiring an update into an empty Composer or a new Folder/Environment in Composer. Note that you can only import containers that were originally created using Composer. Make your corrections to the object(s) in Composer. You can then regenerate a new Deployment container including the corrected object and deploy it on the Synchrony server.
l l
Note
In the ServertoComposer approach, the Deployment container you import must contain all of the objects affected by the update you plan to perform. This may not be the case is a series of deployment containers have been deployed on the same server.
Deployment Guide 63
9 Using Composer for maintenance
64 Deployment Guide

Synchrony Platform 4.4 DeploymentGuide AllOS en

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Synchrony Platform 4.4 DeploymentGuide AllOS en

Caricato da

Copyright:

Formati disponibili

SYNCHRONY DEPLOYMENT GUIDE

March 24, 2011

Synchrony Platform 4.4

Deployment Guide iii

Synchrony Platform 4.4

Specialization: Runtime configuration of servers.

Synchrony Platform 4.4

Disconnected versus connected deployment

Synchrony Platform 4.4

Synchrony Platform 4.4

Synchrony Platform 4.4

Using Composer as the design tool

Creating Deployment containers

Synchrony Platform 4.4

2 Using Composer as the design tool

Deployment container structure

Example of a Deployment container

Synchrony Platform 4.4

Editing the Deployment container

Figure 2. Example of a deployment container directory structure

Editing the Deployment container

Example of a component.xml file

Synchrony Platform 4.4

2 Using Composer as the design tool

Figure 3. component.xml file

Example of an attributes.xml file

Synchrony Platform 4.4

Editing the Deployment container

Figure 4. attributes.xml file

Attributes in an attributes.xml file

Synchrony Platform 4.4

2 Using Composer as the design tool

Modified attributes.xml file

Filter value Filter type category

Synchrony Platform 4.4

Specializing using the File Update Tool

A Synchrony installation file Another attributes file A specific file.

Synchrony Platform 4.4

3 Specializing using the File Update Tool

Launching the tool

fileupdatetool.bat (for Windows) fileupdatetool.sh (for Unix)

-settingsFilePath:<settings file path> -rulesFilePath:<rules file path>

Synchrony Platform 4.4

Log file management

Default value attributes ./attributes.xml

cmd.inputFilePath cmd.inputFileType cmd.attributesFilePath

log.audit.enable log.audit.outputfile language

Log file management

Standard specialization Specialization using identification rules

These processes are done sequentially.

Synchrony Platform 4.4

3 Specializing using the File Update Tool

Synchrony Platform 4.4

Specialization using identification rules

Specialization using identification rules with source value concatenation

Synchrony Platform 4.4

3 Specializing using the File Update Tool

The result is jdbc:oracle:thin:@MYHOSTNAME1:1525:SYN.

Identification rules file

Rule XML element

Synchrony Platform 4.4

Identification rules file