This chapter provides an overview of Enterprise Business Services (EBS) and describes how to design EBS, construct the WSDL for the process EBS, work with message routing, build EBS using Oracle Mediator, implement the Fire-and Forget Message Exchange Pattern, implement Synchronous Request-Response Message Exchange Pattern, and implement the Asynchronous Request-Delayed Response Message Exchange Pattern.
This chapter includes the following sections:
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 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 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.
The purpose of the EBS is to:
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 Developing SOA Applications with Oracle SOA Suite.
You can model EBS operations either as synchronous or asynchronous message exchange patterns (MEPs).
The types of EBS are:
Business Activities
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.
Tasks
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 Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
SOA Core Extension 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 and some 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 SOA Core Extension 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 task EBS, use the WSDLs from the Enterprise Service Library of the SOA Core Extension.
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 can 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 can 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 5-1 illustrates the decision points in establishing the EBS pattern.
Figure 5-1 Identifying the Interaction Pattern for EBS Operations
For more information about EBS types, see "Understanding Enterprise Business Services" in Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
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 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 Working with Security.
For more information about EBS, see "Understanding Enterprise Business Services" in 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 Guaranteed Message Delivery.
To define the EBS service contract:
This section includes the following topics:
These sections describe how to fill in sections of the WSDL.
When constructing the WSDL, consider that:
Oracle's JDeveloper and 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.
You should adhere to the naming conventions for creating service, target namespace, messages, operations, port type, and so on as described in Oracle AIA Naming Standards for AIA Development.
To define message structures in the WSDL types section:
Message Definitions
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.
PortType Definition
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.
Annotating Service Interface
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 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 stamped in the header. EBS rules should not assume the target system ID is 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 runtime, 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 runtime.
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 Pre-Built Integrations 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 5-1 lists the routing rule clauses and the related XPath expressions.
Table 5-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 5-2 shows some routing rules delivered as part of the Integrated Supply Chain Management Pre-Built Integration.
Table 5-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 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 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: CreateSalesOrder/sordebo: SalesOrderLine /sordebo:SalesOrderLineSchedule/ns5:ShipToPartyReference /ns5:LocationReference /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 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 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 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 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:
How to Implement Fire-and-Forget Pattern with EBS One-Way Calls
Creating Mediator Routing Services for Asynchronous Fire-and-Forget Patterns with a One-Way Call EBS
Asynchronous Fire-and-Forget MEP Error Handling Using Compensatory Operations
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 Designing Application Business Connector Services, Constructing the ABCS,, and Completing ABCS Development.
For more information about enabling the EBF, see Designing and Constructing Enterprise Business Flows.
To implement fire-and-forget pattern with EBS one-way calls:
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 SOA Core Extension.
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:
To create Mediator projects for the asynchronous fire-and-forget MEP:
To create routing services for asynchronous fire-and-forget MEP:
The routing rules for the request EBS are the same as those for the synchronous request-response section.
For more information, see How to Create Routing Services for the Synchronous Request-Response MEP.
For more information, see 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 must 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:
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:
How to Implement Synchronous Request-Reply Message Exchange Patterns in EBS
How to Create Mediator Projects for the Synchronous Request-Response MEP
How to Create Routing Services for the Synchronous Request-Response MEP
How to Implement Error Handling for the Synchronous Request-Response MEP
For more information about enabling the ABCS (both requester and provider), see Designing Application Business Connector Services, Constructing the ABCS, and Completing ABCS Development.
For more information about enabling the EBF, see 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:
To create routing services for the synchronous request-response MEP:
For more information, see 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 Designing Application Business Connector Services, Constructing the ABCS, and Completing ABCS Development.
For more information about enabling the EBF, see 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.
To create Mediator routing services:
To create Mediator projects for the request-delayed response MEP:
To create routing services for the request-delayed response MEP:
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 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:
Error Handling Implementation
For more information, see 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:
For more information about enabling the ABCS (both requester and provider), see Designing Application Business Connector Services, Constructing the ABCS, and Completing ABCS Development.