Synchrony Platform 4.4 DeploymentGuide AllOS En

S Y N C H R O N Y D E P L O Y M E N T G U I D E

Synchrony platformVersion 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 anyhuman 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. Thedescriptions and information in this document may not necessarily accurately represent or reflect the current orplanned functions of this product. Axway Software S.A. may change this publication, the product describedherein, or both. These changes will be incorporated in new versions of this document. Axway Software S.A. doesnot 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 andaccess to these sites are provided for your convenience only. Axway Software S.A. does not control, endorse orguarantee 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 thirdpartycontent.

Contents

1 Overview 5

Terminology 5Deploymentcompatible components 5Disconnected versus connected deployment 6Deployment workflow 6

2 Using Composer as the design tool 9

Designing configurations 9Creating Deployment containers 9Deployment container structure 10Example of a Deployment container 10

Editing the Deployment container 11Example of a component.xml file 11Example of an attributes.xml file 12

3 Specializing using the File Update Tool 15

Basic concept 15Launching the tool 16Settings file 16Log file management 17Specialization process 17Identification rules file 20

4 Deploying containers 27

Overview 27Server commands 27Import 27Remove 28List 28Detail 28Help 28Clean 29Export 29

5 Deploying to Integrator 31

About the deployment lifecyle 31Deployment lifecycle process 32

Connect or disconnect Composer 33Linking an Integrator Server to Composer 34Servermode commands 34

Deploying Containers 34Prerequisites 35

SynchronyPlatform 4.4 Deployment Guide iii

Deployment commands 35Which objects can you deploy, andwhen? 39Updating and dependant objects 41About Integrator versioning 42About the update option 42About Container and object dependancy 43

Deployment examples 43Example 1: Firsttime deployment 43Example 2: Deploy a dependant Container 44Example 3: Remove Container that has dependant Containers 45Example 4: Remove Container without dependant Containers 45

Example 5: Deploy dependant Container with newer version of dependant object46

Example 6: Update dependant object used by other objects 46Rolling back to earlier versions 47Example: Rolling back to an earlier Container 47Example: Rolling back to an earlier server configuration 48

Managing Integrator deployment packages remotely 48Installing the batch importer tool 48Using the batch importer tool 49

Importing to a server with a different OS 49Consecutive imports 49

Integrator attribute names 50

6 Deploying to ProcessManager 53

Architecture 53Functionalities 53The Export Deployment Container 54Container overview 54Attributes.xml 55Export Files 57

7 Deploying to Sentinel 59

Deployment commands 59Sentinel attributes management 59

8 Auditing deployment 61

Tracked objects 61ServerLog TO attributes 61Deployment TO attributes 61

Activating deployment monitoring for Composer 62

9 Using Composer for maintenance 63

In connectedmode 63In disconnectedmode 63

iv Deployment Guide SynchronyPlatform 4.4

1Overview

This chapter provides an overview of the deployment functionality.

Terminologyl Axway component:

An Axway component is a software application developed by Axway and potentiallyincluded in the Synchrony platform.

l Deployment container:

A deployment container is a package generated by a design tool that includes all thephysical elements (properties file, implementation settings and so on) necessary forthe dynamic configuration of Axway components.

l Environment:

An environment is a set of system resources (machine, port, database, and so on) andthe runtime part of Axway components.

l Implementation settings:

l Integrator: IntegrationTasks, IntegratorProcesses, MapStages

l ProcessManager: Business processes

l Sentinel: Monitoring requests, Dashboards

l Accounting Integrator: Rules

l Specialization: Runtime configuration of servers.

Deployment-compatible componentsThe deployment functionality can be usedwith the following Synchrony 4.4 platformcomponents using Composer as the deployment tool:

Component Version

Axway Composer 3.7

Axway AccountingIntegrator 1.6

Axway Integrator 3.6

Axway ProcessManager 2.3

Axway Sentinel 3.5

For additional information on the deploymentrelated specificities of each Axwaycomponent, refer to the Componentspecific information section.

SynchronyPlatform 4.4 Deployment Guide 5

#_Component-specific_information





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 andMapping Services as deployment design tool are providedin the componentspecific documentation.

Disconnected versus connected deploymentThe disconnected deployment functionality described in this document fulfils the sameobjective as a Composer broadcast operation or Send to Server command, but withoutrequiring a connection between Composer and the runtime environment.

Therefore disconnected deployment mode enables you to break the communication linkbetween Composer and the component server or Broadcast Agent, and still transferComposer objects between the separate entities.

The connectedmode is best used for the design and simulation phases. However, onceyou have finalized your configuration design, instead of transferring it directly via abroadcast operation or Send to Server command, you create a configuration container.

Deployment workflowThe Synchrony deployment functionality enables you to deploy a given Synchronyplatform configuration in several environments. For example, you can validate aconfiguration in a test environment and then subsequently deploy that configuration topreproduction 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 performedon several environments, to the actual deployment phase of validated configurations.

6 Deployment Guide SynchronyPlatform 4.4

Deployment workflow

1. In Composer, create and update a dynamic Axway component configuration. You thenbroadcast the configuration to a Axway server (The Development environment) fortesting and validation: the new configuration is directly taken into account and easilyremoved from the server.

2. Once validated in Development, export your configuration to a container. Thiscontainer holds all the dynamic runtime configuration information and anattributes.xml file that contains all the data specific to the environment such as thehost name, IP port, URL to the database, and so on.

3. Deploy this container onto an Axway server in a Preproduction environment using athird party deployment tool. .

Specialize the attributes.xml file to match the technical infrastructure of the targetenvironment (the rest of the container must not be modified) using the File updateTool.

4. Once validated in Preproduction, deploy this same container to a Productionenvironment 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 Servercommands section.

The entire workflow can be monitored using the Axway Sentinel. For this, two TrackedObjects can be used: ServerLog and Deployment. For details about these objects, refer tothe Auditing deployment section.

Note In parallel of the deployment tool, you can use source control software to save andrestore all the data deployed.


#_Auditing_deployment

#_Auditing_deployment

1 Overview


2Using Composer as the designtool

This chapter describes how Axway Composer can be used in the deployment operation.

Designing configurationsIn the Synchrony platform, the design tool is Axway Composer. The contents of thedeployment 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 (networktype, protocol, operating system, and so on). In Axway Composer terminology, theAxway component is referred to as the Synchrony Server.

l The IntegrationServices workbench is where you design the dynamic part of thesoftware.

This workbench contains a set of objects that you typically configure andmodify morethan once. In the IntegrationServices workbench, you can: add your Applications andPartners; define communication between Applications, using an underlying SynchronyServer; define communication with Partners

Refer to the Composer online documentation or componentspecific documentation fordetailed procedures andmore information on the different objects you can design.

In the case of Integrator, you begin by importing your existing configuration (createdduring the installation of your Axway components) into Axway Composer. You can thenmodify and supplement the imported objects before going on to create a configurationcontainer. Refer to the Componentspecific information section for more information.

Creating Deployment containersOnce you have designed the configuration for your environment in Composer, you can usethe 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 ordocumentation) 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.





2 Using Composeras the design tool

Deployment container structureA deployment container is a package of standardized folders and files arranged in apredefined hierarchy. Under the root folder, which is effectively the container itself, a subfolder is created for each product. As some products have tomanage 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 thecontainer during its creation. In addition, each deployment container contains a numberof standard files necessary for deployment. These files are described in the table below.

File name and hierarchy Description

[root]/container.xml This xml file identifies thecontainer attributes: name,version, id and description.

[root]/common.txt This text file lists the commondata used by the componentconfigurations included in thecontainer. This data is sharedbetween the targetcomponents runtimeenvironments.

[root]/ auditId.txt This text file contains a uniquecontainer audit identifier usedto audit deployment andrelated operations.

[root]/[Component]/

component.xml

This xml file describes thetarget product attributes:product name and version.

[root]/[Component]/

attribute.xml

This xml file lists allexternalized environmentdependent configuration data(attributes). This file can beedited using the attributesubstitution engine.

Note Date formats are standardized for all date attributes described in thecontainer.xml, attributes.xml and component.xml files: yyyy-mm-ddThh:MM:ss.mmm-Z.

Example of a Deployment container

The following figure illustrates the tree structure of a Deployment container that containsfive components: AccountingIntegrator, Composer, Integrator, ProcessManager, andSentinel.


Editing the Deployment container

Figure 2. Example of a deployment container directory structure

Editing the Deployment containerYou can consult the details of the deployment container content in the component.xmlfile. If required, you can extract the attributes.xml files from the container (one percomponent) andmodify it manually as shown below or using the File update Tool beforedeploying the container. For more information on the latter, see Specializing using the FileUpdate Tool on page 15.

Example of a component.xml file

Description of the structure of a component.xml file:



Figure 3. component.xml file

Example of an attributes.xml file

Description of the structure of an attributes.xml file:


Editing the Deployment container

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>



Modified attributes.xml file

In this example, optional information is added to the attributes.xml file in order todifferentiate how several instances of the same attribute (channel.ftp.MainHostname) areprocessed during deployment. This is achieved by manually adding:

l Filter value

l 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">


<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>


3Specializing using the FileUpdate Tool

This chapter describes how to specialize a deployment container’s attributes.xml filecontaining environmentspecific data, to adapt it to a given target environment.

Basic conceptFile Update Tool version 1.0.2 is installed as part of the Axway Infrastructure componentand is located in the <Synchrony_Home>/Tools directory.

The File Update Tool is a generic tool used to specialize an attributes file with values takenfrom external files.

These external files may be:

l A Synchrony installation file

l Another attributes file

l A specific file.

The tool merges data taken from an external file (input file) with an attributes file. Anoutput file is created with updated attributes. This output file can then be used in acontainer to deploy in the target environment.


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 anattributes file from the container of platform #1, and generates a new attributes file for acontainer for platform #2.

Launching the toolThe File Update Tool application is launched by a script:

l fileupdatetool.bat (for Windows)

l fileupdatetool.sh (for Unix)

The options are described in the following table.

Option Description

-help Display the help

-version Display the application and connector versions

-inputFileTypeList Display the available input file types list

-inputFilePath:<input file

path>

Set the input file path. The path may be absolute orrelative. (Mandatory option)

-inputFileType:<input file

type>

Set the input file type. Default value: “attributes”

-

attributesFilePath:<attributes

file path>

Set the attributes.xml file path. The path is anabsolute or relative file path. Default value:“./attributes.xml”

-outputFilePath:<output file

path>

Set the output file path. The path is an absolute orrelative file path. Default value:“./attributes.new.xml”’

-settingsFilePath:<settings

file path>

Set the properties file path used to initialize theapplication. Default value: “./conf/settings.txt”.

-rulesFilePath:<rules file

path>

Set the merging rules file path. The path may beabsolute or relative.

Settings fileThe following table describes the parameter settings managed by the application.


Log file management

Key Description Defaultvalue

cmd.inputFilePath Absolute or relative input file path

cmd.inputFileType Input file type attributes

cmd.attributesFilePath Absolute or relative attributes.xml filepath

./attributes.xml

cmd.outputFilePath Absolute or relative output file path ./attributes.new.xml

cmd.rulesFilePath Absolute or relative merging rules filepath

./rules.txt

log.audit.enable Enable audit logs false

log.audit.outputfile Audit logs output file audit.log

language Language code (‘en’ or ‘fr’) en

All parameter settings are optional. If parameters are not defined, the default values areused.

For command settings, all parameters defined in the application settings file have priorityover the parameters from the command line. To use the parameters from the commandline, corresponding parameters must not be present in the application settings file.

Log file managementThe File Update Tool is logged by Log4J. Log4J is configured in theconf/log4j.properties file. This file defines a standard configuration.

The console displays FATAL level messages. This level is used by errors which result in thestopping 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). Thisfile 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 processThe specialization process involves two phases:

l Standard specialization

l Specialization using identification rules

These processes are done sequentially.



Standard specialization

Figure 6. Standard merge

In the standard specialization process, the tool compares matching attributes in the inputand attributes files.

Attributes match if they fulfill the following conditions:

l If the attribute name is defined in both files (not empty), the namesmust be equal.Otherwise, if the patterns are defined (not empty), the pattern values must be equal.

l If an attribute filter is defined in both files, then the filter values must be equal (filtertype, category and value).

For each matching attribute, the attribute value of the input file is copied to the attributevalue in the attributes file.


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 tospecialize a destination attribute value with a source attribute value.

The selection is performed using an identification rule that describes the source attributevalue and the destination attribute value. The source selection describes only oneattribute of the input file while the destination selection describes a set of attributes of theattributes file. The tool then copies the source attribute value into all the destinationattribute values.

Specialization using identification rules with source value concatenation



Figure 8. Specialization using identification rules with source value concatenation

Amore 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, asimple string can be inserted into the concatenation.

For example, a JDBC URL can be the result of the concatenation of:

l The string "jdbc:oracle:thin:@"

l The value MYHOSTNAME1 from input attribute A

l The string ":"

l The value 1525 from input attribute B

l The string ":"

l The value SYN from input attribute C

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

Identification rules fileIf a rules file is defined either in the application settings file or in the command line, thespecialization using identification rules are executed.

The role of a rule is to describe a selection of one or more source attributes and one ormore destination attributes.

There are twomodes for source attribute selection:

l Single selection: The rule is composed of only one source attribute. The specializationprocess uses the value of this attribute. See Standard specialization on page 18.

l Multiple selections: The rule is composed of several source attributes. The specializationprocess uses the concatenation of all these attributes. See Specialization usingidentification rules on page 19.

Rule format

The rule file is an XML file. The format of this XML file is defined in the XSDdocumentation/rules/rules.xsd. The directory documentation/rules/ contains someexamples 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 Source

l Destination

The source and destination elements must describe a selection of a set of attributes. Theselection is described in the SelectionAttribute element. An attribute is only selected if allits fields correspond to the SelectionAttribute fields.

SelectionAttribute element

A selection attribute is composed of:


Identification rules file

l A name or a pattern element

l A filterType element (optional)

l A flterValue element (optional)

The process is able to select elements from an attributes list that correspond to theseelements.

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 Concatenationelement.

The concatenation element is composed of a sequence of elements:

l SelectionAttribute

l string

The selection attribute must represent only one attribute from the input file.

The process extracts each attribute representing each selection attribute, andconcatenates the selection attributes and the string value to the same sequence asappears in the file.

Unique source attribute

If the source is composed of only one attribute selection, the application ensures that thesource attribute selection represents only one source attribute from the input file.

If the source is composed of a concatenation, the application ensures that each attributeselection represents only one source attribute from the input file.

Examples

Example of an attributes file:

<Attributes>

<Attribute name="channel.ftp.MainHostName" type="String">


<pattern>${MainHostName_0}</pattern>


<FilterType>Channel</FilterType>

</Attribute>








</Attribute>

<Attribute name="database" type="String">

<value>jdbc:oracle:thin:@localhost:1521:XIP</value>



<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>


</Attribute>

<Attribute name="schemaname" type="String">

<value>SYN</value>


</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>


<name>hostname</name>


</Source>

<Destination>


<name>channel.ftp.MainHostName</name>






</Destination>

</Rule>

</Rules>

Result

<Attributes>






</Attribute>






</Attribute>


<value>jdbc:oracle:thin:@localhost:1521:XIP</value>




</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">



</Attribute>

<Attribute name="portnumber" type="String">

<value>1525</value>


</Attribute>

<Attribute name="schemaname" type="String">



<value>SYN</value>


</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>


<name>hostname</name>


<string>:</string>


<name>portnumber</name>


<string>:</string>


<name>schemaname</name>


</Concatenation>

</Source>

<Destination>


<name>database</name>




</Destination>

</Rule>

</Rules>

Result

<Attributes>








</Attribute>






</Attribute>



<value>jdbc:oracle:thin:@MYHOSTNAME1:1525:SYN</value>



</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 bedefined by an asterisk (*) wildcard. This wildcard is used to substitute a zero or morecharacters. The asterisk wildcard only manages the selection of the destination attribute.

Example 1

<Rule>

<Source>


<name>hostnamePRD</name>


</Source>

<Destination>


<name>hostname*</pattern>


</Destination>

</Rule>

This destination selection attribute selects all attributes in the attributes file that have aname starting with “hostname”.

Example 2

<Rule>

<Source>




<name>hostnamePRD</name>


</Source>

<Destination>


<pattern>${MainHostName_*}</pattern>


<filterValue>Entity.test:ChannelFtp*</filterValue>


</Destination>

</Rule>

This destination selection attribute selects all attributes in the attributes file that have apattern starting with “MainHostName_”, a FilterType’s type equal to “Channel” and afilterValue starting with “Entity.test:ChannelFtp*”.


4Deploying containers

This chapter provides the information necessary to deploy containers using an externaldeployment tool.

OverviewWhen you have created a deployment container with the necessary objects andconfiguration, you must deploy this information to the target environment using thedeployment tool.

All Axway components that support deployment also comply with a list of servercommands related to deployment that can be used in conjunction with a third partydeployment 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: objectconfigurations, container.xml, attributes.xml, component.xml.

l The compatibility and integrity of the configuration files is checked.

l The configuration files are updated using the values in the attributes.xml file.

l The target component repository is updated.

l The list of the imported containers and their details are displayed

l Throughout the steps above, the import and cancel operations are audited.

Server commandsAll Synchrony components that support deployment also comply with a list of servercommands that can be used during the deployment operation.

The main command is –deployment.

Note For Integrator, Sentinel, and ProcessManager do not use these commands aseach component has their own. For details, refer to their dedicated chapters inthis guide.

Import

Description Imports a deployment container. Set either the root folder path of thecontainer or the container identifier if a default container directory isdefined for product in the command line.


4 Deploying containers

Command -import [-update] [-ignoredate] […] {-path <path to

container> | -id <container identifier>}

[-attributesFile <path to attributes file>]

Parameters -path <path to container>: Root folder path of the container to import

-id <container identifier>: Identifier (<Name +''+Version>) ofcontainer to import

-attributesFile <path to attributes file>: You can use anexternal 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.

Remove

Description This command allows you to remove a container.

Command -remove <container identifier> (<Name +'-'+Version>)

Parameters N/A

List

Description This command allows you to display all containers or objects imported andpresent in the repository.

Command -list {-containers | -objects}

Parameters -containers: display the list of containers

-objects: display the list of objects

Detail

Description This command allows you to display the details of an imported container:list of objects.

Command -detail <container identifier> (<Name +'-'+Version>)

Parameters N/A

Help

Description This command allows you to display the help for the list of commands.

Command -help


Server commands

Parameters N/A

Clean

Description This command allows you to remove all imported containers present inthe repository.

Command -clean

Parameters N/A

Export

Description This command allows you to export the deployment container present inthe design repository to the server.

Command -export <destination directory> [-name <container name>] [-

version <container version>] [-description <container

description>] [-objectsList <objects list to export>]

Parameters -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


4 Deploying containers


5Deploying to Integrator

This section provides deploymentrelated information for Axway Integrator.

When deploying to Integrator Servers, you perform different tasks than for othercomponents.

l Install three Synchrony platform environments: design, preproduction, production.

l In the Composer Topography workbench, create an Axway Server object to representan Integrator Server.

l Make sure all the MBC objects on the Integrator Server have been registered correctlyin Copilot. The deployment operation does not deploy or register MBCs. You must dothis manually. For more information, refer to the Integrator Enabler onlinedocumentation.

l Import Environment #1 (development environment with all of the Core Tasks andMBCs that reside on the Integrator Server instance) to Composer as described in theprocedure below.

l Note: In connectedmode, use the importObjectSet command to import theconfiguration directly from the Integrator Server of the development environment. Inconnectedmode, you do not need to export the object set to a deployment containerfile.

l When all configuration design tasks are completed in Composer, export the object setto a deployment container and deploy to preproduction and production.

About the deployment lifecyleTo understand the how Composer and the Integrator Enabler interact with IntegratorServers to deploy an integration from development to preproduction to production, seethe diagram below.


5 Deploying to Integrator

Figure 9. A simplified view of the deployment lifecycle for an integration. See the table belowfor an explanation of the steps.

Deployment lifecycle process

The following table summarizes the steps in the deployment lifecycle as well as theComposer and Integrator commands involved.

To deploy to Perform these steps

Development 1. In Composer, use Send to Server/Remove fromServer to deploy/modify the IntegrationTasks.

If the integration loads objects dynamically, runanother Send to Server operation to deploy thesedynamic objects separely.


Connect or disconnect Composer

To deploy to Perform these steps

Preproduction

Before your first deployment to a preproductionIntegrator Server, you must first establish a linkbetween this server and the Composer instanceused in development.

a. On the preproduction IntegratorServer, runIntegrator deployment -

exportObjectSet.

This generates the file that defines theIntegrator Server configuration for thatparticular server machine. For more onthis command, -exportObjectSet onpage 37.

b. In the Composer TopographyWorkbench, rightclick the IntegratorServer, then select Advanced Actions> Update from file.

This step establishes the link.

2. In Composer, generate a deployment container forthe IntegrationTask. If updating, you must includeany dependant objects. For more about updating,Updating and dependant objects on page 41.

3. On the preproduction Integrator Server, disconnectfrom the Composer, then runIntegrator deployment -import <path to

container>.

Production 4. Create an attribute file that defines the machinespecific settings for the production Integrator Server.

You can use the File Update Tool to create attributefiles. For more information, see the SynchronyDeployment Guide.

5. On the production Integrator Server, runIntegrator deployment -import <path_to_

container>

-attributesFile <path_to_attributes_file>.

Connect or disconnect ComposerYou can deploy objects either in connectedmode, or disconnectedmode. The connectionmode to use depends on the server environment you are deploying to.



l Typically, you deploy to a development environment from Composer . You must be inconnected to Composer to do this. This is known as a connected deployment.

l On the other hand, in a preproduction or production environment, typically you useserver commands to import deployment Containers to the Integrator Server. You mustbe disconnected from Composer to do this. This is known as a disconnecteddeployment.

The servermode command prepares the Integrator Server for deployment by cleaning theIntegrator Server repository and then either connecting to or disconnecting from itscorresponding Axway Composer Server.

Linking an Integrator Server to Composer

Before you can disconnect or connect an Integrator Server instance and a Composerinstance , you must establish a link between them.

1. From the Integrator Server, export the server configuration by running theIntegrator deployment -exportObjectSet command.

2. In Composer Topography Workbench, rightclick the Integrator Server then selectAdvanced Actions > Update from file and import the ObjectSet.

After doing these steps, this Integrator Server will only accept imports from this particularComposer 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 thelinked Composer Server.

Syntax Integrator servermode -connectedBroadcast

-disconnectedBroadcast

Description Cleans Integrator Server repository then disconnects fromthe linked Composer Server.

Syntax Integrator servermode -disconnectedBroadcast

Deploying ContainersThe deployment commands enable you to import Containers directly from an IntegratorServer, or view what has already been deployed.


Deploying Containers

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 IntegratorServer from Composer by using Integrator servermode -disconnectedBroadcast .

Deployment commands

-import

Description Imports a container to Integrator Server.

Syntax Integrator -import <path_to_container> [-update]

[-ignoreDate] [-ignoreServerDate] [-

attributesFile <attribute_file_path>] [-

ignoreMissingMfcs]

Where:

[-update]: Import a new version of alreadydeployedobject.

[-ignoreDate]: Does not compare dates in update mode.

[-ignoreServerDate]: Does not compare dates whenimportingmodified Axway Server object.

[-attributesFile <path_to_attributes_file>]:Modifies target server with these attributes.

[-ignoreMissingMfcs]: Does not return an error if theMFCs are not on target server. Use when deploying toproduction.

Examples Integrator deployment –import

C:\Axway\Synchrony\Integrator\Sample -update

Result:

Imports theC:\Axway\Synchrony\Integrator\Sample\Container.xmlfile into the Integrator Server repository, and updates anydependant objects in the repository where themodification date is earlier than that for the object in thecontainer.

Integrator deployment –import

C:\Axway\Synchrony\Integrator\Sample –update –

ignoreDate

Result

Imports the Sample_container\Container.xml file into theIntegrator Server repository, updates any dependantobjects in the repository regardless of modification date.



Prevent runtime errors with the -ignoreMissingMfcs option

Caution Only use this option when importing to a different Integrator Server than the onedefined in the container.

Deployment containers always include the Axway Server object, which providesconfiguration information for the target Integrator Server. When you deploy toproduction, often the Axway Server in the container does not exactly match theproduction configuration.

To prevent runtime errors on the production Integrator Server, do the following inComposer before importing:

l On the target Integration Server object, register the MFCs used by the container'sIntegrationTask(s).

or

l Verify that the MFCs defined on the Axway Server object in the container are not usedby 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 needsto be deployed on the production server, which is a clone except for some parameters likehostname, ports number,… All these parameters can be defined in the attributes file andreplaced automatically during import.

You can create an attribute file using the File Update Tool. For more information, see theSynchrony Deployment Guide.

-clean

Caution Use this command only when instructed to by Axway Technical Support.

Description Cleans the repository of Integrator Server

Syntax Integrator deployment -clean

SpecialNotes

The -clean command removes:

l all deployed containers

l all coretasks

l resets the runtime server to the originalinstallation configuration (For example, 1 HME,1 PE and so forth).

but keeps:

l registeredMFCs

l installed patches and service packs


Deploying Containers

-remove

Description removes a container from Integrator Server

Syntax Integrator deployment -remove <audit_ID> [-

recursive]

Where:

<audit_ID>: alphanumeric ID for the container. Toretrieve this ID, use -list -containers, or seeAuditID.txt in Container folder.

[-recursive]: removes any other container with objectsthat depend on objects in the container being removed.

Example Integrator deployment -remove d2c310e8-90df-11df-

bbee-000c2976c7df -recursive

Result:

Removes the container, plus any other containers withobjects that depend on objects in the d2c310e890df11dfbbee000c2976c7df container.

SpecialNotes

You must use the recursive option when removingcontainers that were deployed or updated using the -update option. For more information, see Example 3:Remove Container that has dependant Containers on page45.

-exportObjectSet

Description Exports the server configuration for the IntegratorServer.

Syntax Integrator deployment -exportObjectSet

<destination_directory>

Where:

<destination_directory>: Container directory

Example Integrator deployment -exportObjectSet

C:\Axway\Synchrony\Integrator\Containers\Updates

Result:

Creates Export.xml inC:\Axway\Synchrony\Integrator\Containers\Updates

SpecialNotes

Use this file to update objects with destination's IntegratorServer configuration before creating a deploymentcontainer in Composer.



-containerContent

Description Display container content before deployment.

Syntax Integrator deployment -containerContent

<containerDirectory>

Example Integrator deployment -constrainer

C:\Axway\Synchrony\Integrator\Containers

Result:

Displays list of objects in the container.

SpecialNotes

Does not work for containers that have already beenimported. Instead, use Integrator deployment -

detail.

-detail

Description Displays container content after deployment.

Syntax Integrator deployment -detail <audit_ID>

Where:

<audit_ID>: alphanumeric ID for the container.

To retrieve, use -list -containers or see AuditID.txt inthe Container folder.

-list -containers

Description Displays Audit ID for all the deployed containers.

Syntax Integrator deployment -list -containers

-list -objects

Description Displays Audit ID for all repository content.

Syntax Integrator deployment -list -objects


Which objects can you deploy, and when?

-list -mapstages

Description Displays Audit ID for all repository MapStages.

Syntax Integrator deployment -list -mapstages

Which objects can you deploy, and when?When creating a deployment Container, there are only certain objects that can beexplicitly 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 adeployment 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 youcannot.

The table below explains the under what circumstances you should deploy these objects tothe Integrator Server.

For the objects not listed in this table, you cannot create a container or explicltly includethem in any container; they are included automatically when you select the object thatreferences them. For example, if you selected a MapStage when creating a Container, itwould also include the associatedMapBrokers, BusinessDocuments, Tables, Variables,and CustomFunctions.



Deployableobject

When to include in aContainer

What it does

AxwayServer

Tomanage theconfiguration of yourserver independentof any functionalconfiguration.

An Axway Server describes the serverconfiguration (such as the necessaryCommAdapters and Core Tasks). Deploying anAxway Server object therefore adds theCommAdapters and Core Tasks that were notalready on the server.

Removing CommAdapters and CoreTasks

l If you remove CommAdapters andCoreTasks from an Axway Serverobject in Composer, deploying thisAxway Server object will not deletethose CommAdapters and CoreTaskson the physical server. This ensuresexisting functional containerscontinue to run successfully.

l For the same reasons, removing thisobject (either by removing it as asingle object in a container or as oneof several objects in a container)does not delete the CommAdaptersor the Core Tasks.

l To remove Core Tasks andCommAdapters, use the IntegratoroptimizeServer command

IntegrationTask

For a typicaldeployment, this isthe only object youneed to deploy.

Selecting an IntegrationTasks for a containermeans all its associated objects (IntegrationProcess , MapStages, Axway Server andChannels) are included as well.

MapStage To deploydynamicallyloadingMapStages only.

Static Map-Stages

If your integration loads MapStages statically,then they are automatically included in theIntegrationTask container and do not need tobe selected explicitly.

To update, we recommend redeploying theassociated IntegrationTask.

Dynamic Map-Stages

For dynamicallyloadedMapStages, you caneither add the MapStages into the IntegrationTask container or deploy them separately.

l If you consider that the MapStagesbelong to the same project than theIntegrationTask, you wouldprobably include them.


Updating and dependant objects

Deployableobject

When to include in aContainer

What it does

l If you consider them as separatedevelopments (maybe other peopleare doing them), you would create aspecific container for each MapStage. Doing so, you have muchmore flexibility for updates andespecially removal of containers. Thedrawback is that you will have manymore containers to manage.

To update, deploy the updatedMapStage as aseparate container.

Channel To dynamicallyoverride Channelattributes atruntime, you maywant to deploy newChannelsindependently.

This implies that theright Channel iscalled (eg theoverride attributesare set properly).

While you can deploy Channels as independentContainers, it is not mandatory: Channels arelinked to the IntegrationTask and so areautomatically included in the IntegrationTaskcontainer.

That being said, if an update to a Channel'sconfiguration has no real impact on theIntegrationTask, you can deploy the updatedChannel in an independent container.Nonetheless, we still recommended redeployingthe complete IntegrationTask for such cases.

DocumentIdentifier

You must alwaysexplicitly addDocumentIdentifiersto a Container, eitheras an independentContainer, or as anaddition to anothercontainer.

Best practice: addthemwithin anIntegrationTaskcontainer.

DocumentIdentifiers are dynamic objects; theyare not linked to the IntegrationProcess thatuses them.

To add new DocumentIdentifiers intended foran existing IntegrationProcess that doesn'tneedmodifying, you can deploy them as anindependent container.

They will be taken into consideration, as long asthey are called (that’s a matter of setting theattributes properly).

To update a DocumentIdentifier, you candeploy it as an independent container sincethere is no impact on the IntegrationTask.

Updating and dependant objectsAfter your initial deployment to an Integrator Server, you will need to update yourintegrations by importingmodified versions of previouslydeployed objects.



About Integrator versioning

When importing an object , Integrator checks the following:

l Repository name, which is made up of the qualified name + Audit ID

l Modify date

As a safeguard, the Integrator Server does not allow a simple import when there is aversion conflict. If you try to import a Container that includes an object with the samerepository name as an object already on the Integrator Server, the import will fail, unlessyou add the -update option to the end of the command.

Note A repository name in the Integrator Server consists of the object name as itappears in Composer (Company Name.Folder Name.Object Name), plus the AuditID. The Audit ID represents the folder in Composer, the kind of object (BusinessDocument, MapStage, Table, Variable, and so forth), and then the object type forMapBroker and BusinessDocuments. To retrieve the repository name, useIntegrator deployment -list -objects.

About the -update option

When another object with the same repository name already exists in the IntegratorServer 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 themodify date of the object with the same repository name already residing in the IntegratorServer repository, this repository object will be updated to the version of the object in thedeployment container.

Figure 11. Integrator will not allow the import of Container2, because there is a versionconflict: Container1 has an earlier version of the same object.


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 dependantContainer. The object in the dependant Container that is causing the version conflict isknown as the dependant object.

Deployment examplesThese examples, using the Containers shown below, explain how object dependencydetermines which options you must use with the Integrator deployment -import

command.

Figure 13. Container1 and Container2 include the same Map-BrokerMap-Broker err.Container1 and Container3 both include Document-Identifier A, but Container3 includesa 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.



Objective: Deploy Container1.

Command:Integrator deployment -import

Container1

Result:

Successful deployment, Container1 nowresides 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 includesMap-Broker err, which was already deployed inContainer1.

Map-Broker err is a dependant object.

Correct command:Integrator deployment -import

Container2 –update

Result:

Container2 now added to the IntegratorServer.

Container2 is dependant onContainer1.


Deployment examples

Example 3: Remove Container that has dependantContainers

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 alsoincludes Container2, which depends onContainer1.

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 IntegratorServer.

Container2 removed from the IntegratorServer.

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.

CommandIntegrator deployment -remove

{Container2 AuditID}

Result: Remove successful.

You do not need the -recursive option inthis example because no other Containersdepend on objects in Container2.



Example 5: Deploy dependant Container with newer versionof dependant object

Container1 already resides on the Integrator Server.

Objective: Deploy Container3.

CommandIntegrator deployment -import

Container3 -update

Result:

Container3 is added to the IntegratorServer.

Document-Identifier A in Container1 isupdated to Document-Identifier A v.2.

Example 6: Update dependant object used by other objects

Container1 and Container2 already reside on the server.

Objective:

UpdateMap-Broker err , which is common to Container1 and Container2.

l Updating this MapBroker means also updatingMap-Stage A andMap-Stage B to useMap-Broker err v2.

l To deploy the new versions of the MapStages, you must deploy new versions ofContainer1 and Container2.

Commands:Integrator deployment -import

Container1 –update

Integrator deployment -import

Container2 -update

Result:

First command replaces Container1 withContainer1 v2, and updates the dependantobject in Container2 toMap-Broker err v2.

However, sinceMap-Broker err v2 inContainer2 requiresMap-Stage B v2, thisfirst command is not enough.

The second command replaces the existing


Rolling back to earlier versions

Container2 with Container2 v2 whichupdates the MapStage toMap-Stage B v2.

Rolling back to earlier versionsThe examples here describe how you can rollback to earlier versions of Containers orserver configurations, by using the -IgnoreDate or -IgnoreServerDate options whenupdating.

Example: Rolling back to an earlier Container

To deploy a set of objects in a Container (ContainerA, version 1, date 1), you would usethis 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 usethe -update option. Since the date is later than that of the Container currently residingon 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 torollback by deploying the first version that you had previously saved (ContainerA, version1, 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 themodify date of the Container currently residing on the server. Therefore, for Integrator toaccept this import, you must add the -ignoreDate option to the end of the command:

Integrator deployment –import ContainerA –update -ignoredate



Example: Rolling back to an earlier server configuration

To deploy a set of objects in a Container (ContainerA, ServerConf1), you would use thefollowing 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. Thismeans you need to create a new version of ContainerA. Since Containers always includeserver configuration, the server modification will be included in the new Container(ContainerA ,version 2, Serverconf2). Because you are deploying a Container that waspreviously deployed, you must use the -update option. Since the date is later than that ofthe Container currently residing on the Integrator Server, this Container meets thedefault validation criteria.

Integrator deployment –import ContainerA –update

As a result, the objects in ContainerA are updatedwith your modifications, as is the serverconfiguration.

You now deploy ContainerB. The server configuration is older than the one on theIntegrator 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 serverconfiguration (unless there are new configurations needed for the objects in thisContainer).

Managing Integrator deployment packagesremotely

Axway provides a client batch importer tool that you use to execute launcher commandson an Integrator Server from a remote machine. Typically, the batch command is used toautomate 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 theIntegrator Server(s) on which you wish to run the launcher commands.

If Integrator Server is installed using PassPort authentication and authorizationmanagement, you must supply the client batch importer commandwith a valid PassPortusername and password. You can either provide these values during the importer toolinstallation in order to record them in the local system, or enter them directly in the batchcommand 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 batchimporter tool:

1. Using the Synchrony Installation DVD, install the client batch importer on a selectedmachine.

2. During the installation process, enter:


Importing to a serverwith a different OS

l The name of the Integrator Server and access port that you want toconfigure remotely.

l 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 importertool 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 addthe 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 thehost/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 usingPassPort authentication and authorization management.

If you do use PassPort services, and you entered a username and password during theinstallation, the batch importer tool retrieves these values from the stored file on thelocal machine and uses it for authentication with the Integrator Server.

4. After the optional user authentication procedure, the command is executed on theIntegrator Server.

Importing to a server with a different OSWhen importing a container originally designed for a given OS to another type of OS, forexample when you want to import a container originally designed for a Windowsenvironment to a UNIX environment, on the target OS server:

l Run the clean server command.

l Check that the value and format of all related attributes match the parameters definedon the target server.

l If you require any C CustomFunctions, check that they are installed.

l If any MBCs use external libraries, check that these libraries are installed andconfigured.

l If the container uses external products that require libraries, check that they areinstalled and configured.

Consecutive imports

When you import a container originally designed for a given OS to another type of OS, yourun the clean server command beforehand. If you then want to import a second containerthat contains a different Synchrony Server, you must run the clean server commandagain to avoid any conflict between the CoreTask descriptions. Therefore, you cannotimport several containers originally designed for different OS to the same target server.

Note This limitation does not concern containers that only contain MapStages.



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


Integrator attribute names

Channel.CypherString

Channel.Url

Channel.SMTPPort

Channel.POP3Port

CommAdapter.User

CommAdapter.Password

CommAdapter.Port

CommAdapter.DataExchangeDirectory


6Deploying to ProcessManager

This section provides deploymentrelated information for Axway ProcessManager.

ArchitectureThe XML import/export is integrated as part of the Modeler and its code it not usedanymore. It is replaced by a new export XML file, Export Deployment as displayed in thefigure below.

Figure 14. ProcessManager Deployment method

FunctionalitiesFunctionalities 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.


6 Deploying to ProcessManager

Synchrony Deployment ProcessManager Deployment

-import [update] [RD:-

ignoredate] [RD:...]

{-path <path to

container> | -id

<container identifier>}

[RD:-attributesFile

<path to attributes

file>]

import path <path_to_container>

[attributesFiles <path_to_

attributes_file>] [-update]

-list {-containers | -

objects}

list {containers|objects

[<ObjectType>]}

-clean clean

-remove [RD:-

restorepreviousstate]

<container identifier>

remove <Container identifier>

-detail <container

identifier>

detail <Container identifier>

-help help

The Export Deployment ContainerProcessManager 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


The Export Deployment Container

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, Xrepresents the name of the businessDocument.

Attributes.xml

The following table lists some of the ProcessManager attributes.

Object Type Attributename

Pattern

Host TCPCommNetwork

TCPCommNetwork hostname hostname

Axway Server Engine (x) databasename

engine_

dbname

drivertype

engine_

dbtype

databaseport

engine_

dbport

databasehost

engine_

dbhost

customurl

engine_curl

databaseuser

engine_

dbuser

databasepassword

engine_

dbpassword



Object Type Attributename

Pattern

Server CommPoint

ProcessManager handling(x)

user pmHandling_

user

password pmHandling_

pwd

ProcessManager Trigeringby internal queuer (x)

user pmTrigInt_

user

password pmTrigInt_

pwd

Application ProcessManager BusinessRules Repository (x)

repositorytype

pmBRules_

repotype

url pmBRules_

url

user pmBRules_

user

password pmBRules_

pwd

ProcessManager JDBC (x) drivertype

pmJdbc_

drivertype

databaseurl

pmJdbc_

dburl

user pmJdbc_

dbuser

pwd pmJdbc_

dbpwd

ProcessManagerWorkflow (x)

drivertype

pmWfw_

drivertype

databasename

pmWfw_

dbname

port pmWfw_port

user pmWfw_

dbuser

password pmWfw_dbpwd


The Export Deployment Container

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/XMLSchema-

instance" 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 andchannels.xml…). Only server.xml can have attribute values.

Auditing activities

All deployment commands executed in the admin console are logged in logs/manager.logfiles.

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 monitoringmechanism will be used, that is puttingmonitor messages in a MONITOR queue that isread 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’


7Deploying to Sentinel

This section provides deploymentrelated information for Axway Sentinel.

Deployment commandsSentinel complies with the standard list of server commands.

Usage: updates repository.

Command Description

-import<-path path_to_

container>

Imports a container

-clean Removes all imported containers present in therepository

-conf

<configFileName>

Displays the path of the configuration file

-detail <container

identifier>

Displays details of an imported container: list of objects

-list <-containers|-

objects>

Displays all containers or objects imported and presentin the repository

-remove <container

identifier>

Removes a specified container from the repository

-unlockImportMode Unlocks import mode

Sentinel attributes managementTomanage Sentinel attributes, use the Attributes.xml file that is included in eachgenerated container, located at <path to Container>\Sentinel.

Modifiable attributes in the Attributes.xml file:

l SQL Datasource: Manual URL Generation

l SqlDataSource.DatabaseConnection.host

l SqlDataSource.DatabaseConnection.port

l SQL Datasource: Assisted URL Generation

l SqlDataSource.DatabaseConnection.url

l Recommendation: Browser and Custom Type

l Recommendation.Editor.value

l Recommendation.FilePath.value


7 Deploying to Sentinel

l Probe: ScanFile

l Probe.ScanFile.ProbeStringAttribute.filePath

l Probe.ScanFile.ProbeExpression.fileName

l Probe: ExistenceFile

l Probe.ExistenceFile.ProbeStringAttribute.filePath

l Probe.ExistenceFile.ProbeExpression.fileName

l Probe: JDBC

l Probe.JDBC.ProbeStringAttribute.Url

l Probe: Terminal

l Probe.Terminal.Connection.host

l Probe.Terminal.Connection.port


8Auditing deployment

This chapter describes how to audit the deployment operation using Axway Sentinel.

Tracked objectsBroadcast and deployment activity in Composer can be audited using the following AxwaySentinel Tracked Objects:

l ServerLog: used to audit operations and their result.

l Deployment: used to provide details on configurations involved in container operations.As auditing container details can generate large volumes of data, this audit type isoptional.

ServerLog TO attributes

The following information is audited in the ServerLog Tracked Object:

Attributename

Description

ProductName Type of the sender application, for example “Composer Server”

AuditApplicationID Identifier of the sender application: depends on the applicationtype

AuditGroup Group of the audited action

AuditSessionID Unique ID of the user session

AuditUser Identifier of the user that performed the audited action

AuditAction Action name

AuditObjectType Type of object involved in the audited action

AuditObjectName Name of the object involved in the audited action

AuditStatus Status of the action [Success/Failure]

AuditDetail Details of the action (for example, 'export container' or 'importcontainer')

Deployment TO attributes

The following information is audited in the Deployment Tracked Object:


8 Auditing deployment

Attribute name Description

ProductName Type of the sender application, for example “ComposerServer”

AuditDeployUser Identifier of the user that performed the audited action

AuditDeployAction Deployment command

AuditDeployObjectType Type of object involved in the deployment command

AuditDeployObjectName Name of the object involved in the deployment command

AuditDeployObjectDate Validity start date for AccountingIntegrator objects only

AuditDeployStatus Status of the action [Success/Failure]

AuditDeployDetail Details of the action performed by the runtime part of theproduct (Add, Update, Skip, Delete) during import or removeoperations

AuditApplicationID Identifier of the sender application: depends on the applicationtype

CycleID System attribute used tomanage link with ServerLog TO

Activating deployment monitoring for ComposerThe 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 forinformation on monitoring operations.


9Using Composer formaintenance

This chapter describes how tomake corrections to a configuration that has already beendeployed.

In connected modeWhen a communication link exists between Composer and the component server orBroadcast Agent, you can use the Remove from Server and the Send to Server commandsto update deployed objects.

For more information, see the Composer online documentation.

In disconnected modeIf the link between Composer and the component server or Broadcast Agent Indisconnectedmode does not exist, do one of the following:

l Composer to Server

l Update the object(s) requiring corrections in the same Composer environmentused to originally create the Deployment container.

l Make your corrections to the object(s) in Composer.

l You can then regenerate a new Deployment container including the correctedobject(s) and deploy it on the Synchrony server.

l Server to Composer

l Import the deployed deployment container with the object(s) requiring anupdate into an empty Composer or a new Folder/Environment in Composer.Note that you can only import containers that were originally created usingComposer.

l Make your corrections to the object(s) in Composer.

l You can then regenerate a new Deployment container including the correctedobject and deploy it on the Synchrony server.

Note In the ServertoComposer approach, the Deployment container you import mustcontain all of the objects affected by the update you plan to perform. This may notbe the case is a series of deployment containers have been deployed on the sameserver.


9 Using Composer formaintenance


Synchrony Platform 4.4 DeploymentGuide AllOS En

Documents

Transcript of Synchrony Platform 4.4 DeploymentGuide AllOS En