BusinessScope Introducing EBM Header Concepts

23-22 Developers Guide for Oracle Application Integration Architecture Foundation Pack

23.6.3.1 ID

Use this element, shown in Example 23–17 , to identify target systems to route to when the routing rules are overridden. It is populated by the EBS when the target system must be overridden with the value of the participating application instance code.

23.6.3.2 ApplicationTypeCode

This element identifies the type of application. An identifier for the application type where multiple instances of the same application type may be registered in the integration platform. The application type may contain the version number of the application if more than one version is supported on the system. This field, as seen in Example 23–17 , should be populated at the same time as the TargetID field is populated in the EBS or in an EBF, usually in the ABCS. The value of this field should come from the function aia:getSystemTypeID, where ID is the system ID value that is populated in TargetID. EBS routing rules almost always check this field for a value or lack of value when determining the routing target.

23.6.3.3 Custom

This is the complex type that you can extend to add your own elements when needed. Example 23–17 shows an example of target element code. Example 23–17 Target Element Code Sample corecom:Target corecom:IDPORTAL_01corecom:ID corecom:ApplicationTypeCodePORTAL_01corecom:ApplicationTypeCode corecom:Target

23.6.4 BusinessScope

This section captures business scope specification related information defined in UNCEFACT Standard business definition header. Every EBM must contain at least two rows for these elements. ■ One row with type Business Scope describes the end-to-end business process that the message is part of. ■ The second row describes the main message associated in the flow for example, order message in ProcessOrder flow. For most of the cases, each end-to-end process has one message only. However in complex business scenarios there could be multiple messages spawned or forked from the process. In that case each spawned message must be a row in this section. Figure 23–11 describes how this works. Working with Message Transformations 23-23 Figure 23–11 Structure of the BusinessScope Element

23.6.4.1 ID

An optional identifier that identifies the contract this instance relates to. ReqABCSImpl populates this value. This is the name of the process or message given by the applications.

23.6.4.2 InstanceID

A unique identifier that references the instance of the scope for example, process execution instance of document instance. This is an alpha numeric code assigned by the application team concatenated with a GUID. For message type business scope section use the same EBMID as used in the top section.

23.6.4.3 BusinessScopeTypeCode

This element indicates the kind of business scope. Values are: ■ BusinessScope UMM ■ BusinessService for ebXML ■ Message ReqABCSImpl populates this value.

23.6.4.4 EnterpriseServiceName

Name of the EBS where this message belongs. Known to the message creator, be it ABCS or EBS. ReqABCSImpl populates this value.

23.6.4.5 EnterpriseServiceOperationName

Name of the action of the EBS this message belongs. Known to the message creator, be it ABCS or EBS. ReqABCSImpl populates this value.

23.6.4.6 Custom

A complex type for you to extend to add extra elements.

23.6.4.7 How to Add Business Process Information

Every EBM must contain at least two rows for these elements: 23-24 Developers Guide for Oracle Application Integration Architecture Foundation Pack ■ One row with type Business Process describes the end-to-end business process the message is part of. ■ The second row describes the main message associated in the flow, for example, the order message in ProcessOrder flow. In most cases, each end-to-end process has only one message. However in complex business scenarios there could be multiple messages spawned or forked from the process. In that case each spawned message must be a row in this section. The use case example below describes how this works. To keep things simple the example limits the messages to the immediate child of the process and the subsequent chaining of messages is not taken into account.

23.6.5 Use Case: Request-Response