AIA configuration properties

AIA brings us a very nice solution for maintaining variables in one global AIAConfigurationProperties.xml file (kind of ini-file) which are used at runtime. This is the perfect place for e.g. the systemID (application system id) which is used in the code to identify the application for DVM and XRef translations. Also is this systemID used to populate the EBMHeader Sender segment with information from the BSR (Business Service Repository) when the EBM is created in the BPEL RequesterABCSImpl component.

All the aia functions are described and explained in the AIA Development Guide [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009].

Creation of the EBM Header in the transformation xsl file:
<xsl:variable name="serviceName" select="'{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]'"/>
<xsl:variable name="systemID" select="aia:getServiceProperty($serviceName,'Default.SystemID',true())"/>
<xsl:variable name="senderNodeVariable" select="aia:getEBMHeaderSenderSystemNode($systemID,'')"/>
<xsl:variable name="messageIdVariable" select="orcl:generate-guid()"/>

<corecom:EBMHeader>
<corecom:EBMID>
 <xsl:value-of select="$messageIdVariable"/>
</corecom:EBMID>
<corecom:EBMName>
 <xsl:text disable-output-escaping="no">{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Object/V1}SyncObjectListEBM</xsl:text>
</corecom:EBMName>
<corecom:EBOName>
 <xsl:text disable-output-escaping="no">{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Object/V1}ObjectEBO</xsl:text>
</corecom:EBOName>
<corecom:CreationDateTime>
 <xsl:value-of select="xp20:current-dateTime()"/>
</corecom:CreationDateTime>
<corecom:VerbCode>
 <xsl:text disable-output-escaping="no">Sync</xsl:text>
</corecom:VerbCode>
<corecom:Sender>
 <corecom:ID>
  <xsl:value-of select="$senderNodeVariable/ID"/>
 </corecom:ID>
 <corecom:Description>
  <xsl:value-of select="$senderNodeVariable/Description"/>
 </corecom:Description>
 <corecom:IPAddress>
  <xsl:value-of select="$senderNodeVariable/IPAddress"/>
 </corecom:IPAddress>
 <corecom:Application>
  <corecom:ID>
   <xsl:value-of select="$senderNodeVariable/Application/ID"/>
  </corecom:ID>
  <corecom:Version>
   <xsl:value-of select="$senderNodeVariable/Application/Version"/>
  </corecom:Version>
 </corecom:Application>
 <corecom:ContactName>
  <xsl:value-of select="$senderNodeVariable/ContactName"/>
 </corecom:ContactName>
 <corecom:ContactEmail>
  <xsl:value-of select="$senderNodeVariable/ContactEmail"/>
 </corecom:ContactEmail>
 <corecom:ContactPhoneNumber>
  <xsl:value-of select="$senderNodeVariable/ContactPhone"/>
 </corecom:ContactPhoneNumber>
</corecom:Sender>

The configuration properties can also be used to retrieve the service-endpoints, pretty convenient when you'll have to deploy the code to other environments with different endpoints. When the CAVS framework is not used in your organization you can remove the whole CAVS endpoint javacode in the BPEL sourcecode which was generated by the ABCS Service Constructor. Set a webservice endpoint as follows:
<variable name="EndpointReference" element="wsa:EndpointReference"/>

<assign name="SetServiceEndpoint">
  <copy>
    <from>
      <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
        <wsa:Address/>
      </wsa:EndpointReference>
    </from>
    <to variable="EndpointReference"/>
  </copy>
  <copy>
    <from expression="aia:getServiceProperty('{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]','Routing.[PartnerLinkName].EndpointURI',true())"/>
    <to variable="EndpointReference" query="/wsa:EndpointReference/wsa:Address"/>
  </copy>
  <copy>
    <from variable="EndpointReference"/>
    <to partnerLink="[PartnerLinkName]"/>
  </copy>
</assign>

Besides populating the BSR with the application information to populate the EBM Sender elements, by logging into the /AIA site, go to Setup and then tab System, the key field here is System Code = systemID. The properties mentioned above have to be configured in the AIA file before lookup:
$AIA_HOME/config/AIAConfigurationProperties.xml, just above the </AIAConfiguration> tag:
<!-- [ABCSName] -->
<ServiceConfiguration serviceName="{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]">
 <Property name="Default.SystemID">APPLICATION_01</Property>
 <Property name="Routing.[PartnerLinkName].EndpointURI">http://[HTTP_HOST]:[HTTP_PORT]/webserviceaddress</Property>
</ServiceConfiguration>
In the transformation source code (xsl) only the serviceName has to be specified, not the systemID (APPLICATION_01). This systemID gets retrieved from the AIAConfigurationProperties xml file. After editing this file don't forget to reload the AIA Configuration properties: log in the /AIA site, go to setup, go to configuration and after scrolling down you'll find the Reload button.

It's worth to mention that this AIA Configuration Properties file contains environment-specific properties, like partnerlink endpoints. Use the same procedure here as you have for managing connection pools and other physical endpoints/jdbc urls/id's per application per environment.

WSDL artifact errors while deploying

You'll already know that the Oracle JDeveloper contains a nice tool to create the base-mapping (XSL Transformation), unfortunately advanced logic within the mapping get screwed up by this JDeveloper pretty often. Therefor use an advanced text-editor with xml highlighting instead after you finish the base-mapping in JDeveloper. Or stick to the Source-view, no more Design-view.

This leads me to write about a more serious issue with JDeveloper: during development of the integrations all the developers working with ESB components need to have identical workspaces in their JDeveloper. If not, you might run into unwanted errors when deploying. This is known by Oracle and described in a note [ref: note ID 875558.1]:

Applies to: Oracle ESB - Version: 10.1.3.4 to 10.1.3.4.9. This problem can occur on any platform.
Symptoms: When an ESB project is registered using JDeveloper and then moved to a new JDEV Workspace with a different Workspace name, re-registration of the ESB project and its related artifacts (XSL Stylesheets, XML Schemas, WSDL files) might fail.
Cause: ESB artifacts designed with JDeveloper were moved to a different JDeveloper workspace with a new name.
Solution: DO NOT move ESB projects to a different JDEV workspace name. This is not supported by Oracle ESB in the current version.
Explanation: The way ESB identifies a file update in a project at runtime is by using the convention <workspacename>_<projectname>/<filename>. If the user is changing the workspace name, but keeps the project name and file name the same, it will not be possible for JDev to update the related artifacts in the slide repository because the identifier has changed - external references in form of esb:// were created. This is a known limitation.

You might also run into an error while deploying BPEL components that contain a referral to an ESB component, for example in the transformation the target is the ESB component WSDL. This url in the xsl contains the <workspace>, if in development this <workspace> differs from the actual deployed ESB component you might end up seeing the BPEL component in the BPELConsole, but not in the ESB console in BPELSystem. The advice here is: use always the same <workspace> in the JDeveloper, for example let the whole development team develop all ESB components (Projects) under Application AIASystem.

Talking about deployments, there is also a known bug in a jar-file, which is often used by automated deployments, see the note [ref: note ID 1308408.1] which describes the following error:
java.lang.Exception: Programming Error : Adapter Service <WriteData> does not have an associated WSDL artifact
at oracle.tip.esb.jdev.artifacts.model.ESBAdapterServiceArtifactContent.getDeploymentProperties(ESBAdapterServiceArtifactContent.java:159)
For example if you use osbs - Oracle Soa Build Server by Marc Kelderman [ref: http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html], you'll might receive the error as described in the note above. The solution here is to get from Oracle patch 11871410, extract the file ESBMetadataMigration.jar from the deployments.zip file in this patch and put this jar file in the location mentioned in the obbuild.sh script.

Tips to start SOA Suite developments

In order to have all the interfaces in Oracle SOA Suite developed in an uniform way there is a need for coding standards and naming conventions. Oracle delivers the Application Integration Architecture, which includes a canonical model, a test-framework, coding standards, naming conventions and more.

Some tips when starting with Oracle SOA Suite:

• Stick to one version or patch-level for all environments. Only if a new version or MLR (patch-bundle) is needed, for example to fix a showstopper, start a project to upgrade/patch all your environments.
• Developers must have read the AIA Development Guide [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009] or taken an AIA course. As for some the AIA Development Guide is not an easy and fast read, a good practice is to create a summary for those developers :) Add to this summary company-specific coding standards and naming conventions.
• Implement the components in either BPEL or ESB technology based on their purpose. All ABCSs in BPEL, all EBFs in BPEL, all EBSs in ESB, all non-soap communication with applications use ESB adapters.
• Use the AIA Service Generator for the BPEL components (ABCSs). This takes care of code for AIA ErrorHandling, CAVS test framework and sets instance title etc.
• Automate the deployments using scripts or e.g. the osbs - Oracle Soa Build Server by Marc Kelderman [ref: http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html]
• Set xml validation to strict on the development and test environments (except while executing stress-tests).
• Define ownership for all the EBO customizations, DVMs, XRefs, AIA ConfigurationProperties and system-wide parameters.
• When DVM or XRef technology is used for other purposes then intended, prefix the name with for example Z_.
• Define ownership of all the applications within the SOA Suite, especially naming (name per application or per module within, name the middleware communicating with or the application behind), ApplicationObjectLibrary and connection details.
• Define appropriate Service Groups in the ESB System AIASystem, for example one service group per application.
• Transformations from ABM --> EBM should be comprehensive mapping of all available attributes (All ABM Attributes supported in EBM should be mapped). Instance identifying information needs to be populated with as much information as possible in every Identification/IdentificationType element. EBM header needs to be populated fully.
• Use the EBM verbs/EBS operations with care and as intended. For example master data from the System of Record uses the sync, messages to the SoR use create/update.
• The same for EBM List messages, bundling messages lowers the number of instances, but if one message fails all the objects within this message are blocked.

Hope this helps you...