Creating Routing Rules Working with Message Routing

10-8 Developers Guide for Oracle Application Integration Architecture Foundation Pack 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 annotations serve as the source of truth for populating the metadata in the Oracle Enterprise Repository.

10.3.4 How to Check for WS-I Basic Profile Conformance

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.

10.4 Working with Message Routing

This section includes the following topics: ■ Section 10.4.1, Creating Routing Rules ■ Section 10.4.2, Routing at the EBS ■ Section 10.4.3, Guidelines for EBS Routing Rules ■ Section 10.4.4, How to Identify the Target System at EBS

10.4.1 Creating Routing Rules

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. Designing and Developing Enterprise Business Services 10-9 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 10–1 lists the routing rule clauses and the related XPath expressions. Table 10–2 shows some of the routing rules delivered as part of the Integrated Supply Chain Management PIP. Table 10–1 Routing Rule Clauses Clause XPath expression cavs_check = MessageProcessingInstructionEnvironmentCode=PRODUCTION or notMessageProcessingInstructionEnvironmentCodetext ruleset_check = TBD target_system_ identified_check = EBMHeaderTargetApplicationTypeCode=SIEBEL target_system_ absent_check = notEBMHeaderTargetIDtext O2C2 OOTB topology_specific_ clauses = aia:getSystemTypeEBMHeaderSenderID=SIEBEL Table 10–2 Delivered Routing Rules Target Siebel provider ABCS XPath Filter: MessageProcessingInstructionEnvironmentCode=PRODUCTI ON or notMessageProcessingInstructionEnvironmentCodetext and EBMHeaderTargetApplicationTypeCode=SIEBEL or notEBMHeaderTargetIDtext and aia:getSystemTypeEBMHeaderSenderID=SIEBEL Transformation: None Explanation: MessageProcessingInstructionEnvironmentCode=PRODUCTI ON 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. 10-10 Developers Guide for Oracle Application Integration Architecture Foundation Pack

10.4.2 Routing at the EBS