Overview
Configuration
Develop and Build
Project Documentation
The ESB plugin can be configured via the pom.xml or via command line options.
Make sure to specify the correct packaging type according to your project type.
One of the most common configuration tasks is to define the container mapping for an SDM model. Therefore the pom.xml of the SDM model project has to be adjusted. This mapping defines in which ESB container(s) a service instance will be deployed. By default all service instances will be deployed to the default ESBContainer (name=ESBContainer). If a service/process instance is selected by a dedicated container pattern it is removed from the default container. An instances can be added to multiple dedicated containers.
Note: The name DefaultContainer in the configuration is just the name of the Java class which implements the mapping and has no further meaning.
The ContainerMap element can contain the following sub-elements:
Setting useESBDefaultIncludes to false can be useful when you want to import service instances or processes into the domain but you don't want to create an ESB container for them.
Setting useMFDefaultIncludes to false can be useful when you want to import ESB containers into the domain but you don't want to create an MF container for them.
The DefaultContainerSetting has the following Elements that can be set in order to change the ESB Container Configuration:
An mapping example can be found below. All pattern elements support regular expression patterns.
The esbContainerSettings/DefaultContainerSetting/includes/DefaultIncludePattern supports the following includeProperties:
The mfContainerSettings/DefaultContainerSetting supports the following extra settings:
<build>
<plugins>
<plugin>
<groupId>com.progress.maven.plugins.sonicesb</groupId>
<artifactId>maven-sonicesb-plugin</artifactId>
<configuration>
<containerMap>
<esbContainerSettings>
<!-- This is the Default ESB Container -->
<DefaultContainerSetting>
<name>ESBContainer</name>
</DefaultContainerSetting>
<!-- more than one can be specified -->
<DefaultContainerSetting>
<!-- ESB Container name-->
<name>TechnicalAdapters</name>
<busConnection>routing.test.jms</busConnection>
<routingHttpConnection>routing.test.http</routingHttpConnection>
<enablePayloadCapture>true</enablePayloadCapture>
<useForLookingGlass>true</useForLookingGlass>
<useIntraContainerMessaging>true</useIntraContainerMessaging>
<includes>
<DefaultIncludePattern>
<!-- matched against the service instance info attribute. See snippets -->
<pattern>(.*)TechnicalAdapter.OFF(.*)|(.*)TechnicalAdapter.ON(.*)</pattern>
<includeProperties>
<property>
<!-- classpath pattern for the ESB Container -->
<name>classpathPattern</name>
<!-- regex to match nothing, to have no additional jars on the classpath -->
<value>#</value>
</property>
<property>
<name>instances</name>
<!-- Number of service instances -->
<value>10</value>
</property>
<property>
<!-- regex pattern to sort the classpath entries ; is used as a separtor-->
<name>classpathSortPattern</name>
<value>.*aopalliance.*;.*camel-core.*;.*camel-spring.*;.*spring-aop.*;.*spring-beans.*;.*spring-context.*;.*spring-core.*;.*spring-tx.*;.*jaxb-impl.*;.*activation.*;.*jaxb-api.*;.*stax-api.*;.*CamelProcessors.*;.*CamelService.*;.*quartz.*;.*MailService.*</value>
</property>
</includeProperties>
</DefaultIncludePattern>
</includes>
</DefaultContainerSetting>
</esbContainerSettings>
<mfContainerSettings>
<!-- This is the Default MF Container -->
<DefaultContainerSetting>
<name>@MFESBContainer@</name>
<bootContainer>true or false</bootContainer>
</DefaultContainerSetting>
<DefaultContainerSetting>
<name>@container_name_from_tailoring_properties@</name>
<includes>
<DefaultIncludePattern>
<pattern>TechnicalAdapters</pattern>
<includeProperties>
<property>
<name>Hosts</name>
<value>ESBHost</value>
</property>
</includeProperties>
</DefaultIncludePattern>
</includes>
</DefaultContainerSetting>
</mfContainerSettings>
</containerMap>
</configuration>
</plugin>
</plugins>
</build>
The esbContainerSettings and mfContainerSettings elements may be placed outside the pom, in a file called src/main/sonicesb/ContainerProperties.xml. This file supports only the esbContainerSettings and mfContainerSettings elements and their children.
The format of this file is as follows:
<configuration>
<containerMap>
<esbContainerSettings> ... </esbContainerSettings>
<mfContainerSettings> ... </mfContainerSettings>
</containerMap>
</configuration>Parameters can be selected via the parameterMatches parameter. This is done in the POM of the service type or in an external file located at src/main/sonicesb/ESBTailorProperties.xml.
Regular expression patterns can be used to select parameters. The default pattern is ".*", which will select all parameters.
Defined in the POM File you will need to add
<build>
<plugins>
<plugin>
<groupId>com.progress.maven.plugins.sonicesb</groupId>
<artifactId>maven-sonicesb-plugin</artifactId>
<configuration>
<parameterMatches>
<param>(test).*</param>
<param>param2</param>
</parameterMatches>
</configuration>
</plugin>
</plugins>
</build>If not defined in the POM file, you can define them in the ESBTailorProperties.xml file in the following way:
<ESBTailoringRules>
<parameterMatches>
<param>Port</param>
<param>Protocol</param>
<param>Host</param>
<param>SecurityPrincipal</param>
</parameterMatches>
</ESBTailoringRules>By default, queues are assigned to the last Queues element in the SDM Model.xml file. If you want to change this behavior you can create a file called QueueMappings.xml in the src/main/sonicesb directory. The contents of this file should be as follows:
<queueMappings>
<defaultMapping>
<id>defaultQueuesElement</id>
<parameterSet>defaultQueue</parameterSet>
<suppressJNDI>true</suppressJNDI>
</defaultMapping>
<queueMapping>
<id>applicationABCQueues</id>
<parameterSet>applicationEntryQueue</parameterSet>
<suppressJNDI>false</suppressJNDI>
<includes>
<include>.*entry$</include>
</includes>
</queueMapping>
<queueMapping>
<id>applicationABCQueues</id>
<includes>
<include>(applicationa|applicationb)\..*</include>
<include>applicationc\..*</include>
</includes>
<excludes>
<exclude>applicationd.*</exclude>
</excludes>
</queueMapping>
</queueMappings>Note: The parameter suppressJNDI is valid only for SDM version 7.6.x or below. From version 8.0 the JNDI generation has changed, and this parameter is no longer valid
This will cause the Queues to be assigned to the queue element that matches any include regular expression but none of the optional exclude regular expressions. The first mapping that matches a queue get the queue assigned. If no mappings match the queue, it will be assigned to the queues element mentioned in the defaultMapping setting.
includes are required in the queueMapping element, excludes are optional. Neither may appear in the defaultMapping element. When there is no defaultMapping element, the last Queues element in Model.xml becomes the default. You can set the defaultMapping to a non-existent Queues element to force explicit definitions for all queues in the SDM model. The build will fail when the Queues element for a certain queue does not already exist.
Custom StringReplaceMaps can be used to enable the tailoring of values that are otherwise not available for tailoring by the normal mechanism, for example the URL of WebServices to be invoked. A complete description of the StringReplaceMap functionality can be found in the Sonic Deployment Manager documentation, but essentially it is a simple search and replace mechanism.
Custom StringReplaceMaps are defined a file called: src/main/sonicesb/ESBTailorProperties.xml as per the following example. Note that multiple stringReplaceMap tags may be defined.
<ESBTailoringRules>
<CustomStringReplaceMaps>
<stringReplaceMap name="StringToBeReplaced" updatedName="@NameOfVariableToBeUsedInTailoringFiles@"/>
</CustomStringReplaceMaps>
</ESBTailoringRules>As noted above, the StringReplaceMap functionality is a simple search and replace mechanism and as such, can cause issues with strings being unexpectedly modified if insufficient context is provided in the StringToBeReplaced.