How to Design Extensions-Aware ABCS

Completing ABCS Development 13-7 Figure 13–4 Provider-Specific ABCS Using Fire-and-Forget Interaction Style The first extensibility point made available to the implementers of the Provider ABCS can be used to inject code to perform tasks such as custom validation, message alteration, message filtering and so on. The custom code has access to EBM that is about to be transformed. The custom code can return either an enhanced EBM or raise a fault. The second extensibility point can be used to perform custom message augmentation. The extensibility point can be used to inject code to perform tasks such as ABM enhancement, custom validation and so on. The custom code has access to ABM that is about to be used for invocation of application service. The custom code can return either an enhanced ABM or raise a fault. The third extensibility point can be used to inject code to perform tasks such as custom validation, message alteration, message filtering and so on. The custom code has access to ABM that is about to be transformed to EBM. The custom code can return either an altered ABM or raise a fault. The fourth extensibility point can be used to perform custom message augmentation. The extensibility point can be used to inject code to perform tasks such as EBM enhancement, custom validation and so on. The custom code has access to EBM that is about to be used for invocation of callback services. The custom code can return either an altered EBM or raise a fault.

13.1.3 How to Design Extensions-Aware ABCS

Each of the extensibility points is modeled as a service operation having a well-defined interface. ABCS authors define these interfaces. The extensibility interfaces consist of service operations that the ABCS invokes to execute the custom message enrichment or transformation or validations specific code implemented by the customer. 13-8 Developers Guide for Oracle Application Integration Architecture Foundation Pack Each ABCS is accompanied by a corresponding customer extension service. A request-response ABCS has four extensibility points, therefore, the ABCS extension service has four service operations. For a fire-and-forget ABCS, the corresponding ABCS extension service has two service operations. As delivered, the implementation of these service operations for all of the ABCS extension services invokes the same piece of code that always returns the same message. This piece of code has been implemented as a Servlet. The ABCS is developed to invoke the appropriate service operation at each of the extensibility points. To minimize overhead, a check is made to ensure that the service for the relevant extensibility interface has been implemented. Oracle AIA Configuration properties have one property for each extensibility point. Setting the property to Yes indicates that there is a custom implementation for the extensibility point. The default value for these properties is No, therefore, the ABCS never invokes the implementations of these extensions as they were delivered. Table 13–1 lists the service operations for the requester ABCS-specific extensibility points: Figure 13–2 lists the service operations for the provider ABCS-specific extensibility points: AIA recommends that the ABCS and that the customer extension services be co-located. In SOA 11g, when the services are deployed on the same server, the SOA 11g run time uses native invocation. AIA recommends that the extension service should be enlisted as part of the ABCS transaction. When the extension service is implemented using SOA 11g technology, then set the transaction property bpel.config.transaction to required on the extension service to enlist itself in the ABCS transaction. For more information, see Section 13.6.1, How to Ensure Transactions in AIA Services . Table 13–1 Service Operations for Requester ABCS-Specific Extensibility Points Extensibility Point Service Operation Name Just before the execution of transformation of ABM to EBM Pre-ProcessABM Just before the invocation of the EBS Pre-ProcessEBM Just before the execution of transformation of EBM to ABM Post-ProcessEBM Just before the invocation of callback service or response return Post-ProcessEBM Table 13–2 Service Operations for Provider ABCS-Specific Extensibility Points Extensibility Point Service Operation Name Just before the execution of transformation of EBM to ABM Pre-ProcessEBM Just before the invocation of Application Service Pre-ProcessABM Just before the execution of transformation of ABM to EBM Post-ProcessABM Just before the invocation of callback EBS or response return Post-ProcessEBM Completing ABCS Development 13-9

13.1.3.1 Configuration Parameters

Operations at the extension points are invoked based on the values of the specific parameters in the file AIAConfigurationProperties.xml. Each service configuration section specific to an ABCS requires that these parameters be specified. The parameters for each of the four extension points are: ■ ABCSExtension.PreXformABMtoEBM ■ ABCSExtension.PreInvokeEBS ■ ABCSExtension.PostInvokeEBS ■ ABCSExtension.PostXformEBMtoABM ■ ABCSExtension.PreXformEBMtoABM ■ ABCSExtension.PreInvokeABS ■ ABCSExtension.PostInvokeABS ■ ABCSExtension.PostXformABMtoEBM These parameters must be configured with value true for a service invocation. When these parameters are not specified in the configuration section for an ABCS, the value considered by default is false. The intent of this section is to provide developers with a set of guidelines on how to create and leverage these configuration properties to optimize extensibility. The service operation names and extension configuration properties provided in this section are recommendations only Also, it is not within the scope of this discussion to provide guidelines for extension points for every one of the invocations. The number of parameters for any particular ABCS could be different. Product management and engineering teams are best equipped to identify the additional extension points where additional extensibility is required. IT organizations developing services that could potentially be extended by the departmental teams or by their partners will find a need for ABCS to made extension aware. Given this use case, if a customer has to develop ABCS with additional extension points than the recommended, they can come up with appropriate names by following the appropriate naming conventions for service operation names and configuration properties similar to the currently proposed properties.

13.1.4 Designing an ABCS Composite with Extension