esb_deploy - Progress Sonic ESB Deployment Guide 8.5 - Product ...

Chapter 3: Mapping ESB Artifacts to Target Domains
Adding Parameters to Existing ServiceTypes
The parameters of an ESB configuration element define its functionality and its bindings
to a target domain’s requirements, service levels, and physical topology. While the
functionality is intended to stay constant, the bindings must be adjusted when the ESB
element is brought into another domain.
While predefined service types expose the most common parameters for tailoring, you
might want to add (or remove) some parameters that can be mapped.
For example, the configuration file for the service SplitJoinForEach.xml has several init
parameters, only two of which are stated as required in the default tailoring rules file. If
you want to tailor the Boolean parameter Keep Original Part to toggle from its default
value false to true in deployment, add its parameter in your tailoring rules file as follows:
Adjusting EndpointRules
For an endpoint, you need to be aware of required destination names, particularly for the
type QUEUE as queues must be statically defined before they are referenced. These queues
will need to exist in the target domain. Other endpoint parameters are generally accepted
as they have been defined.
You might also provide a preferred name or pattern for destinations. For example, you
could redefine a destination name RIA.entry to be controlled by ACLs you define for
com.myCorp.# by changing the destination name to com.myCorp.RIA.entry.
Adjusting ConnectionRules
For a connection, the parameters exposed provide the parameters for management
connection in the target domain, as well as SSL parameters that specify locations on local
systems. Or, if you do not use SSL for management connections, you could leave those
parameters off the tailoring rules so that they are not exposed.
70 Progress Sonic ESB Deployment Guide 8.5