Monday, May 9, 2011

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

No comments:

Post a Comment