Overview
Configuration
Develop and Build
Project Documentation
This part will introduce you to the development of an ESB Process using the maven plugin.
We advise you to look at existing ESB Processes on int-factory in the SonicPartnerCodeshare/Projects location. These projects can offer an initial guidance to start.
You can also create Arche-Types for your developers. However, this will not be handled in this users-guide.
As depicted in the image, the plugin is working with a standard maven layout. The important locations are:
The Maven-Plugin for ESB Processes is allowing you to work in the way you would normally deliver a normal old-school project. You use the Process editor in order to define your Process, define transformations etc, and upload it to the Sonic DS. It is your task as a developer to include the dependencies on the ESB Service Types that you are using in your Process. Please do NOT set dependencies to libraries used by the ESB Service Types. These libraries will already be inherited by the Serice Types Themselves.
When starting a new ESB Process, you need to define all the used artifacts in the local Sonic DS. During the maven build of your ESB Process, the used artifacts will be extracted from the DS and copied into the /deployed/generated-sources folder in order to facilitate head-less builds without the need for a Sonic DS that is running. In case the maven build detects a used artifact that is not in your local environment, the build will fail and stop. Please make sure that you also check-in the /deployed directory into your SCM as it is important to the buil.
In case you need to continue an existing ESB Process, you will need to check-out the project on your machine. The first action to take is to use the Sonic ESB Deployment Import tool in order to upload the needed resources into your local Sonic Domain. Once this action is completed, you need to build your ESB Process using Maven. Once this is done, you can find required xar files in the Target Directory. In case you do not have the ESB Service Types in your local environment, you can use this XAR file to include it into your environment using the ESB Deployment Import Tool.
Some Service Types can use custom Endpoint Definitions or other artifacts from the Sonic DS that are not automatically found for export using the Sonic ESB Export Utilities (through dependencies). An example for this can be that people use the Inherit From Container property on the ESB Endpoints. At that point, the export tool is not detecting the Connection Definition and as such will not export it for the ESB Process. Using the ExportProperties.xml file at that moment will avoid issues further in the life-cycle.
<export>
<ignore>
<artifact type="ESB" path="/Endpoints/iocc.Error"/>
</ignore>
<roots>
<artifact type="SonicFS" path="/Resources/servicebase.properties"/>
<artifact type="SonicFS" path="/Resources/log4j.properties"/>
<artifact type="SonicFS" path="/System/SonicESB/7.6/Common/jsHelperFunctions.js"/>
<artifact type="SonicFS" path="/System/SonicESB/jsHelperFunctions.js"/>
<artifact type="ESB" path="/Endpoints/iocc.Tracking"/>
<!-- ESB connection used by all flows and-->
<artifact type="ESB" path="/Connections/ioccConnection"/>
</roots>
</export>
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.
Snippets are small pieces of information that are gathered and saved by the Plugin. They are used by other parts in the plugins in order to build items automatically like adding used Queues to a broker definition or identify the needed configuration parameters.
The snippets generated by the ESB Service Type artifact are:
<?xml version="1.0" encoding="UTF-8"?>
<Queues>
<Queue>
<Id>GFO.SVNHudsonIntegration.Process.Fault</Id>
</Queue>
<Queue>
<Id>GFO.SVNHudsonIntegration.Process.RME</Id>
</Queue>
</Queues><?xml version="1.0" encoding="UTF-8"?> <ServiceInstances> <ServiceInstance name="GFO.svn2hudson.CBR" hint="com.aurea.gfo.governance.process.GFOSvnHudsonIntegration.GFO.svn2hudson.CBR"/> <ServiceInstance name="GFO.svn2hudson.EffectivePomCreator" hint="com.aurea.gfo.governance.process.GFOSvnHudsonIntegration.GFO.svn2hudson.EffectivePomCreator"/> <ServiceInstance name="GFO.svn2hudson.HudsonJobAdapter" hint="com.aurea.gfo.governance.process.GFOSvnHudsonIntegration.GFO.svn2hudson.HudsonJobAdapter"/> <ServiceInstance name="GFO.svn2hudson.MailSender" hint="com.aurea.gfo.governance.process.GFOSvnHudsonIntegration.GFO.svn2hudson.MailSender"/> <ServiceInstance name="GFO.svn2hudson.Prototype" hint="com.aurea.gfo.governance.process.GFOSvnHudsonIntegration.GFO.svn2hudson.Prototype"/> <ServiceInstance name="GFO.svn2hudson.XForm" hint="com.aurea.gfo.governance.process.GFOSvnHudsonIntegration.GFO.svn2hudson.XForm"/> <ServiceInstance name="OrderDataService" hint="com.aurea.gfo.governance.process.GFOSvnHudsonIntegration.OrderDataService"/> <ServiceInstance process="GFO.svn2hudsonIntegration" name="BPEType" hint="com.aurea.gfo.governance.process.GFOSvnHudsonIntegration.process.GFO.svn2hudsonIntegration"/> </ServiceInstances>
<?xml version="1.0" encoding="UTF-8"?> <Variables> <Variable name="@svc.GFO.svn2hudson.EffectivePomCreator.GlobalSettingsFile@"/> <Variable name="@svc.GFO.svn2hudson.EffectivePomCreator.UserSettingsFile@"/> <Variable name="@svc.GFO.svn2hudson.HudsonJobAdapter.HudsonHost@">gfo-build.progress.com</Variable> </Variables>
<groupId>your.group.id</groupId>
<artifactId>artifactId</artifactId>
<version>1.0-SNAPSHOT</version>
<name>Short Name</name>
<packaging>esb</packaging>
<description>Small description of what this Process is doing</description>
<url>http://Servcer/location-to-doc/${project.groupId}/${project.artifactId}/${project.version}</url> <build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<!-- Assemble all dependencies with repository layout -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.2</version>
<configuration>
<reportPlugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>2.6</version>
<!-- <configuration> <dependencyDetailsEnabled>false</dependencyDetailsEnabled>
<dependencyLocationsEnabled>false</dependencyLocationsEnabled> </configuration> -->
<!-- simpler configuration without reportSets available for usual
cases -->
<!-- <reports> <report>dependencies</report> <report>scm</report>
</reports> -->
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jdepend-maven-plugin</artifactId>
</plugin>
</reportPlugins>
</configuration>
</plugin>
<plugin>
<groupId>com.aurea.maven.plugins</groupId>
<artifactId>sonicesb-maven-plugin</artifactId>
<version>${maven-sonicesb-plugin.version}</version>
<extensions>true</extensions>
<configuration>
<containerMap>
<esbContainerSettings>
<DefaultContainerSetting>
<name>ESBContainer</name>
</DefaultContainerSetting>
</esbContainerSettings>
<mfContainerSettings>
<DefaultContainerSetting>
<name>@MFESBContainer@</name>
</DefaultContainerSetting>
</mfContainerSettings>
</containerMap>
</configuration>
</plugin>
</plugins>
</build>