| Oracle® Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.4.0) E17364-02 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.4.0) E17364-02 |
|
Previous |
Next |
This chapter describes how to design and develop Enterprise Business Services (EBSs).
This chapter includes the following sections:
ISection 12.1, "Introduction to Enterprise Business Services"
Section 12.6, "Implementing the Fire-and-Forget Message Exchange Pattern"
Section 12.7, "Implementing the Synchronous Request-Response Message Exchange Pattern"
ISection 12.8, "Implementing the Asynchronous Request-Delayed Response Message Exchange Pattern"
EBSs are the foundation blocks in Oracle Application Integration Architecture (AIA). An EBS represents the application or implementation-independent Web service definition for performing a business task, and the architecture facilitates distributed processing using EBS. Since an EBS is self-contained, it can be used independently of any other services. In addition, it can be used within another EBS.
For more information about EBS, see "Understanding Enterprise Business Services" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
You must construct an EBS when the business process integration is between multiple source applications and target applications using the canonical model.
Provide the mediation between the requesting services and providing services.
Provide different operations invoked from a requester Application Business Connector Service (ABCS), an EBS, or an Enterprise Business Flow (EBF).
Route an operation to a suitable EBS, EBF, or provider ABCS based on the evaluation of the various routing rules for an operation.
Oracle AIA leverages Mediator technology available in Oracle SOA Suite to build the EBS.
The EBS is implemented as a Mediator routing service. A Mediator service has an elaborate mechanism to hold multiple operations of the EBS, create routing rules for each operation, perform XSLT transformation, and define endpoints for each routing rule.
For more information about using Oracle Mediator, see "Using the Oracle Mediator Service Component" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
You can model EBS operations either as synchronous or asynchronous message exchange patterns (MEPs).
The types of EBS are:
They represent an atomic business unit of work that has a set of steps involving system-to-system interaction. They are exposed as mediator services with implementations through ABCSs or EBFs.
They provide an aggregated, real-time view of enterprise data. They are primarily Create, Read, Update, Delete (CRUD) operations acting on the Enterprise Business Object (EBO) and its business components. They are exposed as mediator services with implementations through ABCS. They eliminate point-to-point links at the data level and direct dependency on data models of data sources.
For more information about EBS types, see "Understanding Enterprise Business Services" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
AIA Foundation Pack is shipped with an EBS library. The EBS library consists of the service definitions delivered for the all of the EBOs present in the Enterprise Object Library. These are shipped as WSDL files. The service operations present in the EBS typically are the CRUD operations plus some of the operations specific to entities.
All the operations of the EBS WSDLs, of type Data Services, in the Enterprise Business Service Library are modeled as asynchronous one-way services. The only exceptions are the Query operations and Validate operations. These are modeled as synchronous request-response operations with a named fault.
You can review the sample WSDLs provided in the AIA Foundation Pack under the AIAComponents/EnterpriseServiceLibrary folder.
Review each of the WSDLs, the operation's description, and the metadata before deciding to create either a new service or an operation.
Any new EBS that you create must be of type Activity Service, with operations put in to meet the requirements of integration solution being developed.
The new EBS should be put in a different WSDL and not added to the entity EBS WSDLs.
This section includes the following topics:
The methodology for designing and implementing an EBS is a contract-first methodology, that is, the contract is defined and created before the EBS is implemented. The contract for an EBS is defined as a WSDL document.
For the business task EBS, use the WSDLs from the Enterprise Service Library of the Foundation Pack.
For the business activity EBS, use the TemplateEBS.wsdl available in the Foundation Pack and create a process EBS WSDL. Customers wanting to create a new EBS for an EBO that was not delivered as part of Enterprise Object Library can use TemplateEBS.wsdl as a model to create the new WSDL.
Service operations supporting the synchronous request-response MEP are defined in one port type. The operation should have input, output, and fault message defined.
Service operations supporting fire-and-forget MEP should be defined in one port type and the operation must have an input message defined.
Service operations supporting an asynchronous request-delayed response pattern should have two operations, one for sending the request message and another for processing the response message. Each of these two operations must have an input message. Two different portTypes exist, one for each operation. The service operation for processing the response message should reside in a port type that has Response as the suffix.
The EBS WSDLs should have two kinds of portTypes:
A portType for all operations used for modeling synchronous request-response operations and request-only operations. The name does not specify the Request.
A portType for asynchronous response operations. The name specifies Response.
You should create two Mediator routing services for each of the portTypes.
When designing EBS, consider the following:
What is the service for?
Your enterprise should have only one EBS for a particular business function, and it should be independent of any application.
The service can implement multiple business operations defined in EBS WSDL.
It should have implementations for all the business operations for a business object.
The service should also contain response operations, which are required for the asynchronous request-response pattern.
How will the service be invoked?
The service is invoked using HTTP transport as a Web service.
When the calling client is co-located with this service, then the call can be configured to be a local invocation using optimized binding to improve performance and propagate transactions.
What invokes the service?
The service can be invoked by an application if the application has the capability to send an Enterprise Business Message (EBM) and can perform all the functions of requester ABCS.
When the application does not have the capability to invoke this service directly, then the requester ABCS invokes this service.
An EBF flow that orchestrates across multiple business objects can also invoke this service.
How do you interact with the application?
If the application has the capability to receive the EBM message, the EBS can call the application using HTTP as Web service call.
If not, then you must create and call a provider ABCS.
What type of interaction is between client and EBS?
The client can call EBS using any of the three MEPs.
Since the MEPs for the entity EBS WSDLs in the EBS library are predefined, you must design the process EBS WSDLs. The EBS is modeled to have multiple operations. Each operation leads to the execution of the EBS for a particular business scenario requirement and is granular in nature. Thus, each operation can be modeled to support a different interaction style or pattern.
Figure 12-1 illustrates the decision points in establishing the EBS pattern.
For more information about EBS types, see "Understanding Enterprise Business Services" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
To establish the MEP for a new process EBS:
Identify the triggering event for the EBS operation based on the understanding of the business process requirement from the functional design.
If the control is to be blocked until a response is returned to the point of invocation, then choose the EBS request-reply pattern.
This is a synchronous call. In this case, the EBS operation has input and output messages with a named fault.
If, after the EBS is invoked, the triggering point does not wait for the response and continues, this invocation of the EBS would be an asynchronous call.
Next, check whether the execution of the EBS results in a response.
Should the request and the response be correlated? If the answer is yes, then this is a delayed response. Use the EBS request-delayed response pattern. In this case, the EBS has two portTypes, each of which accepts an input message only and each of them belongs to a different port.
If the answer is no, then choose the EBS fire-and-forget pattern. In this case, the EBS operation has an input message only.
The EBS should be configured to rethrow the errors back to the invoking client. Ensure that the application error handling capabilities are in line with the integration platform error handling capabilities.
For more information about error handling, see Chapter 24, "Configuring Oracle AIA Processes for Error Handling and Trace Logging".
When the invoking client (requester ABCS or application) is remote, the EBS must be enabled with security as described in the security chapter.
For more information about security, see Chapter 25, "Working with Security."
For more information about EBS, see "Understanding Enterprise Business Services" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
Based on the SOA transaction semantics in Oracle Fusion Middleware, you can design and configure transactions across ABCS, EBS, and EBF.
For more information, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
For details about how to guarantee message delivery, see Section 15.7, "Guaranteed Message Delivery".
To define the EBS service contract:
Identify the EBS and the operations it must support.
Identify the interaction patterns for each of the operations in EBS.
Identify the EBMs to be used for the requests and responses (if any) pertaining to each of the operations.
This section includes the following topics:
Section 12.3.1, "Introduction to WSDL Construction for the Activity Service EBS"
Section 12.3.4, "How to Check for WS-I Basic Profile Conformance"
These sections describe how to fill in sections of the WSDL.
When constructing the WSDL, consider that:
Oracle's JDeveloper, as well as text editing tools, can be used to create the WSDL.
The EBM schema module for the EBO must be referenced in the WSDL.
The WSDL should reference the schema modules hosted on the central location.
Annotations should be done based on the recommendations provided in Chapter 11, "Annotating Composites".
You should adhere to the naming conventions for creating service, target namespace, messages, operations, port type, and so on as described in Chapter 29, "Oracle AIA Naming Standards for AIA Development".
To complete the <definitions> section:
Name
The service contains operations related to creation and maintenance as well as actions to be performed on an EBO.
Namespace
Mark this namespace as the target namespace.
Namespace prefixes
Define a namespace prefix for the newly identified namespace:
wsdl is the namespace prefix for the default namespace.
xsd is the namespace prefix for XMLSchema.
soap is the namespace prefix for the SOAP namespace.
A namespace prefix must be defined for the EBO. The namespace prefix should be the same as the EBS WSDL in the delivered EBOs.
To define message structures in the WSDL types section:
Import the appropriate schema that has all of the relevant EBMs defined.
Use xsd:import to import the elements from a schema.
Ensure that the namespace attribute for the xsd:import element is the same as the target namespace for the schema document you import.
Also, ensure that the namespace prefix is declared for that namespace so that the elements in the imported schema can be referenced using the namespace prefix.
The attribute targetNamespace for the xsd:schema element should be the same as the targetNamespace for this WSDL.
For every operation, you must create a message for sending requests and another message (optionally) for receiving responses, depending on the pattern you selected.
The message for sending the requests should be the same as the operation followed by ReqMsg.
The response message should be the same as the operation followed by RespMsg.
You should define a portType name for each operation, and it should be the same as the service name. You defined the message names specified for input and output elements in the message definitions section based on the pattern. When services are deployed, Mediator appends Service to the port type to form the service name that goes under the service section in the concrete WSDL.
Sections of the WSDL allow documentation where the details of the sections can be annotated. WSDL authors must annotate the sections thoroughly, and in a manner similar to the way existing EBS WSDLs are annotated. The annotations serve as the source of truth for populating the metadata in the Oracle Enterprise Repository.
The WS-I Basic Profile consists of a set of nonproprietary Web services specifications, along with clarifications, refinements, interpretations, and amplifications of those specifications that promote interoperability.
Conformance to the Profile is defined by adherence to the set of requirements for a specific target, within the scope of the Profile.
This section includes the following topics:
The routing rules in the EBS routing service operations are used to decide to which target end point the incoming message should be routed.
Follow these guidelines when creating routing rules:
Routing rules must first be defined functionally and always with a specific integration topology in mind.
In most cases, routing logic should be performed in the routing rules of the EBS.
However, all routing rules in the EBS should check for and respect existing target system IDs that are already stamped in the header. EBS rules should not assume the target system ID is already populated.
Requester ABCS should not determine target systems or stamp target system IDs in the EBM header.
For any EBS operation, each possible target application system instance requires a routing rule.
For example, if two Siebel provider application system instances exist, SEBL_01 and SEBL_02, then each must have a routing rule even though both rules target the same Siebel provider ABCS.
Alternatively, if functional requirements dictate that only a single instance of the application type can receive the message at run time, then a single rule could be used and an XSLT would be invoked to stamp the ID of the one instance to be used at run time.
When an EBS operation has multiple provider application system instances of the same application type (such as SEBL_01 and SEBL_02), the routing rules for each instance must have an XSLT to stamp the appropriate system instance ID in the EBM header so that the provider ABCS that is shared between the multiple instances can identify which instance to invoke and cross-reference.
If an EBS operation is a synchronous request-reply pattern or asynchronous request-delayed response pattern, then the routing rules must be mutually exclusive given the actual topology of the Oracle AIA system.
Routing rules are delivered with Process Integration Packs (PIPs) as part of Mediator routing services.
These rules are designed to work for the delivered topology. If you implement any changes to the delivered topology, such as adding an additional system instance, then you must implement your own complete set of routing rules.
The standard routing rule clause structure is:
(cavs_check) and (ruleset_check) and ( (target_system_identified_check) or ((target_system_absent_check) and (topology_specific_clauses))
Table 12-1 lists the routing rule clauses and the related XPath expressions.
Table 12-1 Routing Rule Clauses
| Clause | XPath expression |
|---|---|
cavs_check) = |
MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or not(MessageProcessingInstruction/EnvironmentCode/text())) |
ruleset_check) = |
TBD |
target_system_identified_check) = |
EBMHeader/Target/ApplicationTypeCode='SIEBEL' |
target_system_absent_check) = |
not(EBMHeader/Target/ID/text()) |
O2C2 OOTB (topology_specific_clauses) = |
aia:getSystemType(EBMHeader/Sender/ID)!='SIEBEL' |
Table 12-2 shows some of the routing rules delivered as part of the Integrated Supply Chain Management PIP.
Table 12-2 Delivered Routing Rules
| Target | Siebel provider ABCS |
|---|---|
XPath Filter: |
(MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or not(MessageProcessingInstruction/EnvironmentCode/text( )))and (EBMHeader/Target/ApplicationTypeCode='SIEBEL' or ( not(EBMHeader/Target/ID/text()) and aia:getSystemType(EBMHeader/Sender/ID)!='SIEBEL' ) ) |
|
Transformation: |
None |
|
Explanation: |
MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or is missing entirely and either Target application type is already specified as Siebel, or else no Target is specified and the Sender application type is not Siebel. |
|
Target: |
Oracle EBusiness provider ABCS |
XPath Filter: |
(MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or not(MessageProcessingInstruction/EnvironmentCode/ text())) and ( EBMHeader/Target/ ApplicationTypeCode='EBIZ' or ( not(EBMHeader/Target/ID/text()) and aia:getSystemType(EBMHeader/Sender/ID)!='EBIZ' ) ) |
|
Transformation: |
None |
|
Explanation: |
MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or is missing entirely and either Target application type is already specified as EBiz, or else no Target is specified and the Sender application type is not EBiz. |
|
Target: |
CAVS |
XPath Filter: |
MessageProcessingInstruction/EnvironmentCode='CAVS' |
|
Transformation: |
None |
|
Explanation: |
MessageProcessingInstruction/EnvironmentCode='CAVS' |
Routing rules are specified for each operation defined on EBS services. The system uses routing rules to determine where to route the incoming EBM, either to an EBF, EBS, ABCS, or the Composite Application Validation System (CAVS). Routing rules are specified as XPath expressions in the filter of the Mediator routing rule.
Routing rules must be mutually exclusive since all the rules are evaluated and messages are routed to an end point based on the rule evaluation.
At a minimum, each EBS operation should have these rules:
One routing rule for CAVS enabling.
This rule should check whether the EBM Header > MessageProcessingInstruction > EnvironmentCode is set to CAVS.
One or more routing rules to connect to the provider ABCS or EBF.
The filter expression specified in these routing rules must ensure that the message is not a test message.
For each ABCS or EBF, one routing rule exists. The conditions can be one of these:
Target system ABCS populated in the EBM header
Example of a filter expression for a SalesOrderEBS routing rule for determining the target system ABCS:
In this case, the filter has an expression to check whether the target system ABCS in the EBM header was prepopulated and the Override Routing Indicator is set to False.
/sordebo:QuerySalesOrderEBM/ns5:EBMHeader/ns5:Target/ns5:ID = "SEBL78_01" and /sordebo: Query SalesOrderEBM/ns5:EBMHeader/ns5:Target/ns5: Override RoutingIndicator = "false"
Content-based routing
In this case, the content of the EBM is evaluated to determine the target system ABCS. The filter expression should ensure that the target system information was not prepopulated in the EBM header.
Example expression:
starts-with(/sordebo: CreateSalesOrderEBM/sordebo: DataArea/sordebo: Create SalesOrder/sordebo: SalesOrderLine/sordebo:SalesOrderLineSchedule/ns5:ShipToPartyReference/ns5:Loc ationReference /ns5:Address/ns5:CountrySubDivisionCode,'9') and /sordebo:CreateSalesOrderEBM/ns5:EBMHeader /ns5:Target/ns5:ID = ""
Parallel Routing
EBS should use parallel routing when you want each target service to invoke in its own transaction and retry the target service.
For more information, see Chapter 13, "Designing Application Business Connector Services."
Enable error handling and logging
EBS should handle errors to allow clients or administrators to resubmit or retrigger processes through a central error handler.
For more information, see Chapter 24, "Configuring Oracle AIA Processes for Error Handling and Trace Logging".
The EBS can route the request from the Requester ABCS, an EBF, or another EBS to one of the many provider ABCS available. The target system must be identified only for Create operations. For all other operations, the Xref function lookupPopulatedColumns is used to identify the systems in which the data synchronization of entity has been done. A combination of steps listed below leads to the correct ABCS.
To identify the target system at EBS:
Using content-based routing.
The routing rule in the EBS is based on the content of the message and is used to decide the target ABCS. This is used only for the Create operation. This is the case when the target system information in the EBM header is empty and has not been set as yet.
After the target system is determined, it is set in the EBM header. This information is used for all subsequent services - like other EBS or ABCS.
Using the target system information in the EBM header.
If the target system information is already set in the EBM, this is used for routing to the correct ABCS.
From the XREF for operations other than Create.
For all operations other than Create, the target system has been determined and the cross-reference IDs have been set. In this case, use the XREF function lookupPopulatedColumns to identify the systems in which the data synchronization of the entity has been done.
You can use the Oracle Mediator component to build a component in an EBS composite.
Although Oracle AIA allows any technology to be used for developing an EBS service, use Mediator in most situations.
To develop the Oracle Mediator Service:
In JDeveloper, create a new SOA composite project.
Open the composite.xml in Design mode.
Add a Mediator component in the components swim lane.
Add a Web service as external reference service in the references swim lane.
This reference service could represent a provider ABCS.
You should use a concrete WSDL of the provider ABCS. That is, you should pre-deploy the service that is being referred to as an external reference.
Wire the Mediator component to the external reference component created in step 4.
Open the Mediator component and configure routing rules.
Create an assign by copying the input variable to the output variable as shown in Figure 12-2.
To implement both asynchronous MEPs (fire-and-forget and request-delayed response), you must create EBS WSDLs and then create one or two Mediator routing services, depending upon the MEP. Next, implement the requester and provider services, adhering to the guidelines laid out for the respective MEPs.
The requesting service can be a requester ABCS (BPEL process), EBF (BPEL process), or a participating application.
The providing service can be a provider ABCS (BPEL Process), EBF (BPEL process), or a participating application.
This section includes the following topics:
Section 12.6.1, "How to Implement Fire-and-Forget Pattern with EBS One-Way Calls"
Section 12.6.4, "Asynchronous Fire-and-Forget MEP Error Handling Using Compensatory Operations"
Section 12.6.5, "How to Invoke the Compensate Operation of EBS"
Section 12.6.6, "How to Enable Routing Rules in Compensate Operation Routing Service"
The initiator for a fire-and-forget pattern is a requesting service not waiting for or expecting a response. The requesting service can be a participating application, a requester ABCS Impl, or an EBF. In each of these cases, the request payload must be an EBM request.
For more information about enabling the ABCS (both requester and provider), see Chapter 13, "Designing Application Business Connector Services", Chapter 14, "Constructing the ABCS", and Chapter 15, "Completing ABCS Development".
For more information about enabling the EBF, see Chapter 17, "Designing and Constructing Enterprise Business Flows".
To implement fire-and-forget pattern with EBS one-way calls:
Create EBS WSDLs.
Create a Mediator routing service for asynchronous fire-and-forget patterns with one-way call EBS.
Route the request from the requesting service to correct providing service in the routing service of the one-way call operation of the request EBS.
Implement error handling for logging and notification based on fault policies.
|
Note: These steps are in addition to the regular steps required for the requesting service and the providing service. |
For the entity EBS, use the WSDLs from the Enterprise Service Library of the Foundation Pack.
For the process EBS, use the TemplateEBS.wsdl available in the Foundation Pack and create a Process EBS wsdl.
Service operations supporting a synchronous request-response MEP must be defined in one port type and the operation must have input, output, and fault message defined.
Service operations supporting a fire-and-forget MEP must be defined in one port type and the operation must have an input message.
Service operations supporting asynchronous request-response pattern must have two operations, one operation for sending the request message and another operation for processing the response message.
Each of these two operations must have an input message alone. You should have two different portTypes, one for each operation. The service operation for processing the response message must reside in a portType having Response as the suffix.
The EBS WSDLs must have two portTypes:
PortType for all operations used for modeling synchronous request, response operations and request-only operations. The name must not specify Request.
PortType for asynchronous response operations. The name must specify Response.
Two Mediator routing services must be created for each of the portTypes.
To create Mediator routing services for asynchronous fire-and-forget patterns with a one-way call EBS:
Create Mediator projects.
Create routing services.
Create routing rules.
Implement error handling.
To create Mediator projects for the asynchronous fire-and-forget MEP:
Create two Mediator projects, one for each of the portTypes in the EBS WSDL.
If all of the service operations for an EBS have either a synchronous request-response or fire-and-forget pattern, then all of these operations must reside in only one portType so there would be only one Mediator routing service.
If the EBS has at least one asynchronous request-response operation, then there should be two port types - two Mediator Routing Services and two Mediator projects (one for each of the routing services).
Follow the naming conventions detailed in Appendix: Oracle AIA Naming Standards.
Examples of typical names for the Mediator projects:
CustomerPartyEBSV2 (This has a routing service with all operations for synchronous request-response and request-only.)
CustomerPartyEBSResponseV2 (This has a routing service with all operations for asynchronous request-response.)
To create routing services for asynchronous fire-and-forget MEP:
Put the EBS WSDL in the Mediator project folder.
Create a routing service and name according to the naming convention detailed in Appendix: Oracle AIA Naming Standards.
Select the WSDL.
The WSDL must be parsed and the portType name filled in the portType field of the routing service.
Select the portType matching with the routing service. Save the routing service.
The routing service created for a portType must have all the operations specified in that portType in the EBS WSDL.
The routing rules for the request EBS are the same as those for the synchronous request-response section.
For more information, see Section 12.7.3, "How to Create Routing Services for the Synchronous Request-Response MEP".
For more information, see Chapter 24, "Configuring Oracle AIA Processes for Error Handling and Trace Logging".
To offset the effects of errors in the provider services, operations can be added to the EBS to trigger compensation in the requesting services for one-way calls. This can be achieved by having compensatory operations in the EBS.
Compensatory operations, modeled as one-way calls are separate operations. For each request-only operation in the request portType, there must be an operation for triggering compensation.
For example: CompensateCreateCustomer, CompensateCreateOrder.
Compensatory operations are invoked in cases where a business exception is likely to result in a irrecoverable error. The conventional retry and resubmit is not possible and the correction is required to be made in the requesting service.
In this situation, you must implement suitable compensatory taking advantage of the participating applications compensatory action web services or APIs.
In error handling, you may need to ensure that compensatory actions are taken for some errors so the compensate operation of the EBS is invoked from the providing service. The compensate operation of the EBS routes to the correct compensating service.
To invoke the compensate operation of the EBS:
For an error in the providing service, raise an exception and catch it in the catch block.
In the catch block, construct the request EBM along with the fault component in the EBM header.
Create a transform step and select the input variable representing the request EBM and the compensate variable, also representing the request EBM.
When an exception is generated, put the exception details in a variable and pass that as input to the compensation XSLT.
Map the following to the compensate variable:
Standard EBM header content from the request EBM
Data area from the request EBM
Fault message
Set the InvokeCompensate step to invoke the corresponding compensate operation in the request EBS routing service.
Route the compensate request to a suitable compensating service.
Figure 12-3 illustrates the fire-and-forget pattern with the compensation operation.
There must be two routing rules.
To enable routing rules in compensate operation routing service:
Routing rule for the compensate operation of EBS.
The information populated in the <EBO Name>ResponseEBM\corecom:EBMHeader\Sender\ WSAddress/ WSAddress/wsa:FaultTo/wsa:ServiceName in the requesting service is used to route the request for compensation to the correct compensating service in the compensate operation of the EBS.
Put this routing rule in the compensate operation of the EBS:
<EBO Name>ResponseEBM\corecom:EBMHeader\Sender\ WSAddress/ WSAddress/wsa:FaultTo/wsa:ServiceName = <Compensating Service Name>
Routing rule for CAVS.
If the test case created in CAVS is of type asynchronous delayed-response, then the response message can come to the CAVS endpoint and be correlated back to make the test pass/fail. For this to happen, an explicit invoke to the CAVS system endpoint must exist: http://host:port/AIAValidationSystemServlet/asyncresponserecipient
The initiator for a synchronous request-reply pattern is a requesting service waiting for and expecting a response. The requesting service can be a participating application, requester ABCS Impl, or an EBF. In each of these cases, the request payload would be an EBM request and the response payload would be an EBM response.
This section includes the following topics:
Section 12.7.1, "How to Implement Synchronous Request-Reply Message Exchange Patterns in EBS"
Section 12.7.2, "How to Create Mediator Projects for the Synchronous Request-Response MEP"
Section 12.7.3, "How to Create Routing Services for the Synchronous Request-Response MEP"
Section 12.7.4, "How to Implement Error Handling for the Synchronous Request-Response MEP"
For more information about enabling the ABCS (both requester and provider) see Chapter 13, "Designing Application Business Connector Services", Chapter 14, "Constructing the ABCS", and Chapter 15, "Completing ABCS Development".
For more information about enabling the EBF, see Chapter 17, "Designing and Constructing Enterprise Business Flows".
To implement synchronous request-reply MEP in EBS:
Create Mediator projects with routing services.
Create routing rules to route the request from the requesting service to the correct providing service in the routing service of the EBS.
Implement error handling for logging and notification based on fault policies.
To create Mediator projects for the synchronous request-response MEP:
Follow these guidelines when creating Mediator projects:
Create two Mediator projects, one for each of the portTypes in the EBS WSDL.
If all of the services operations for an EBS have either synchronous request-response or fire-and-forget pattern, then all of these operations must reside in only one portType, so only one Mediator Routing Service should exist.
If the EBS has at least one asynchronous request-response operation, then two portTypes should exist, two Mediator routing services and two Mediator projects (one for each routing service).
Follow the naming convention detailed in Appendix: Oracle AIA Naming Standards.
Examples of typical names for the Mediator projects are:
CustomerPartyEBSV2 (This example has a routing service with all operations for synchronous request-response and request-only.)
CustomerPartyEBSResponseV2 (This example has a routing service with all operations for asynchronous request-response.)
To create routing services for the synchronous request-response MEP:
In JDeveloper, put the EBS WSDL in the Mediator project folder.
Create a routing service and name according to the naming convention detailed in Chapter 29, "Oracle AIA Naming Standards for AIA Development".
Select the WSDL. The WSDL must be parsed and the portType name filled in the portType field of the routing service.
Select the portType matching with the routing service. Save the routing service.
The routing service created for a portType must have all the operations specified in that portType in the EBS WSDL.
For more information, see Chapter 24, "Configuring Oracle AIA Processes for Error Handling and Trace Logging".
The initiator of the request-delayed response pattern is a requesting service that invokes the request EBS and waits for a response. The requesting service can be a participating application, requester ABCS Impl, or an EBF. In each of these cases, the request payload is an EBM request and the response payload is an EBM response.
For an error in the providing service, a response message with error information is constructed and returned to the requesting service for action.
This section includes the following topics:
For more information about enabling the ABCS (both requester and provider) see Chapter 13, "Designing Application Business Connector Services", Chapter 14, "Constructing the ABCS", and Chapter 15, "Completing ABCS Development".
For more information about enabling the EBF, see Chapter 17, "Designing and Constructing Enterprise Business Flows".
To implement the request-delayed response pattern with the two one-way calls of the EBS:
|
Note: Perform these steps in addition to the regular steps required for the requesting service and the providing service. |
Create EBS WSDLs.
Create Mediator routing services for asynchronous request-delayed response patterns with two one-way call EBSs.
Route the request from the requesting service to the correct providing service in the routing service of the one-way call operation of the request EBS.
Implement error handling for logging and notification based on fault policies.
Route the response message in the EBS response to the correct requesting service.
Figure 12-4 illustrates the request-delayed response pattern:
To create the EBS WSDLs for the request-delayed response MEP:
For the entity EBS, use the WSDLs from the Enterprise Service Library of the Foundation Pack.
For the process EBS, use the TemplateEBS.wsdl available in the Foundation Pack and create a Process EBS WSDL.
The EBS WSDLs must have two portTypes:
PortType for all operations used for modeling synchronous request-response operations and request-only operations.
The name must not specify the Request. Service operations supporting the synchronous request-response MEP must be defined in one portType, and the operation must have input, output, and fault message defined.
PortType for asynchronous response operations.
The name must specify Response. Service operations supporting asynchronous request-response pattern must have two operations, one operation for sending the request message and another for processing the response message.
Two Mediator routing services must be created for each of the portTypes.
To create Mediator routing services:
Create Mediator projects.
Create routing services.
Create routing rules.
To create Mediator projects for the request-delayed response MEP:
Create two Mediator projects, one for each of the portTypes in the EBS WSDL.
If all of the services operations for an EBS have either synchronous request-response or fire-and-forget pattern, then all of these operations must reside in only one portType, so only one Mediator routing service is used.
If the EBS has at least one asynchronous request-response operation, then two portTypes must exist, two Mediator Routing Services and two Mediator Projects (one for each routing service).
Follow the naming convention detailed in Chapter 29, "Oracle AIA Naming Standards for AIA Development".
Examples of typical names for the Mediator projects are:
CustomerPartyEBSV2 (This example has a routing service with all operations for synchronous request-response and request-only.)
CustomerPartyEBSResponseV2 (This example has a routing service with all operations for asynchronous request-response.)
To create routing services for the request-delayed response MEP:
Put the EBS WSDL created into the Mediator project folder.
Create a routing service and name according to the naming convention detailed in Chapter 29, "Oracle AIA Naming Standards for AIA Development".
Select the WSDL.
The WSDL must be parsed and the portType name filled in the portType field of the routing service.
Select the portType matching with the routing service. Save the routing service.
The routing service created for a portType must have all the operations, including compensate operations, specified in that portType in the EBS WSDL.
|
Note: These guidelines are in addition to the implementation of asynchronous message exchanging patterns. |
For the asynchronous request-delayed response EBS, routing rules must be created for both request and response.
Routing Rules for Request EBS
The routing rules for request EBS are the same as those explained in the synchronous request-response section.
For more information, see Section 12.7.3, "How to Create Routing Services for the Synchronous Request-Response MEP".
Routing Rules for Response EBS
There must be two routing rules.
To create routing rules for the response EBS:
Routing to the correct requesting service.
When multiple requesting services from multiple participating applications are invoking a request EBS and are waiting for a delayed response, then you must route the response to the correct requesting service.
As illustrated in Figure 12-5, set the EBMHeader/Sender/WSAddress/wsa:ReplyTo/wsa:ServiceName to the name of the requesting service name in the requesting service-Application Business Message (ABM) to EBM transformation-before invoking the request EBS.
In the providing service, this information is transferred from the request EBM to the response EBM. This information is used in the response EBS by putting a routing rule in the filter as:
<EBO Name>ResponseEBM\corecom:EBMHeader\Sender\ WSAddress/wsa:ReplyTo/wsa:ServiceName = <Requesting Service Name>
The target endpoint for the evaluation of this rule should be set to the requesting service.
For every requesting service of the request EBS that is waiting for a response EBS to send back a response, specify a routing rule as shown above.
CAVS routing rule.
The CAVS routing rules are the same as that explained in the Sync Request-Response section.
For more information about enabling the ABCS (both requester and provider) see Chapter 13, "Designing Application Business Connector Services", Chapter 14, "Constructing the ABCS", and Chapter 15, "Completing ABCS Development".
Error Handling Implementation
For more information, see Section 24.5, "Implementing Error Handling and Recovery for the Asynchronous Message Exchange Pattern to Ensure Guaranteed Message Delivery."
In the asynchronous request-delayed response MEP, the requesting service is in a suspended mode, waiting for a response. If there is an error in the providing service, the response to the requesting service includes the details of the error.
To handle errors in the asynchronous request-delayed response MEP:
In case of an error in the providing service, raise an exception and catch it in the catch block.
In the catch block, construct the response EBM along with fault component in the EBM header.
Create a transform step and select the input variable representing the request EBM and the output variable representing the response EBM.
Pass the fault message generated from the exception as a variable into the 'input variable to fault variable' XSLT.
Map to the output variable:
Standard EBM header content from the request EBM including the correlation information
Fault message
Set the Invoke step to invoke the response operation in the response EBS routing service.
Route the response from the providing service to the correct requesting service.
For more information about enabling the ABCS (both requester and provider), see Chapter 13, "Designing Application Business Connector Services", Chapter 14, "Constructing the ABCS", and Chapter 15, "Completing ABCS Development".
|
 Copyright © 2001, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
