This appendix describes the fields and attributes that must be passed to make Oracle Application Integration Architecture (Oracle AIA) processes fallout-compliant.
New services introduced, which need to participate in the order fallout notification mechanism, must be included in the AIA Error Notifications table with the appropriate Error_Type and Error_Ext_Handler.
For all system or composite faults (binding and remote), the fault policy is initiated and publishes a notification message. By ensuring that your process has the following context information supplied, the order fallout management extension handler application programming language (API) constructs an enriched fault message.
All the enterprise business messages (EBMs) for order processing passes the following information as a sender reference in the EBMHeader. This list shows the information that you are required to pass for fallout:
Order ID - Business Component ID of the Order - SalesOrder / Provisioning Order / Fulfillment Order / Fulfillment Billing Order
Order Number - ID of the order - FulfillmentOrder#/ProvisioningOrder#/SalesOrder# (optional - required only if available)
SalesOrderID - Alternate Object Key - storing the Sales Order Common ID
Sales Order Number - Alternate Object Key - storing the Sales Order Number (Siebel CRM value)
Sales Order Revision Number - Alternate Object Key - storing the Sales Order Number (Siebel CRM value)
Common Account ID - Alternate Object key - storing the Common Account ID
Account ID - Alternate Object key - storing the Siebel CRM Account ID (only for Sales Order EBM because the account information in the Xref is rolled back)
Account Name - Alternate Object Key - storing the Siebel CRM Account Name
Along with these fields, populate the SchemeID field indicating the name, and the SchemeAgencyID indicating the column name.
The attribute value for schemeAgencyId of SALESORDER_NUMER is considered the system code of the system from which the order was placed (Order Originating System Code)
This information should be entered in the EBM Header in the following path:
EBMHeader / Sender / ObjectCrossReference / SenderObjectIdentification /
Example J-1 is a sample EBMHeader section.
Example J-1 Sample EBMHeader Section
<EBMHeader>
<Sender>
<ObjectCrossReference>
<SenderObjectIdentification>
<BusinessComponentID> OrderId</BusinenessComponentID>
<ID> Order# (if any)</ID>
<ApplicationObjectKey>
<ID schemeID="SALESORDER_ID"schemeAgencyID="SEBL_01">SalesOrderID</ID>
</ApplicationObjectKey>
<AlternateObjectKey>
<ID schemeID="SALESORDER_ID " schemeAgencyID="COMMON">SalesOrderCommonID</ID>
</AlternateObjectKey>
<AlternateObjectKey>
<ID schemeID="SALESORDER_NUMBER" schemeAgenyId="SEBL_01">SalesOrderNumber</ID>
</AlternateObjectKey>
<AlternateObjectKey>
<ID schemeID="SALESORDER_REVISION" schemeAgenyId="SEBL_01">SalesOrderRevision</ID>
</AlternateObjectKey>
<AlternateObjectKey>
<ID schemeID="CUSTOMERPARTY_ACCOUNTID" schemeAgenyId="COMMON">CommonAccountID</ID>
</AlternateObjectKey>
<AlternateObjectKey>
<ID schemeID="CUSTOMERPARTY_ACCOUNTID" schemeAgenyId="SEBL_01">Siebel Account ID</ID>
</AlternateObjectKey>
<AlternateObjectKey>
<ID schemeID="CUSTOMERPARTY_ACCOUNTNAME" schemeAgenyId="SEBL_01">Account Name</ID>
</AlternateObjectKey>
</SenderObjectIdentification>
</ObjectCrossReference>
</Sender>
</EBMHeader>
Only the underlined elements are required for the SalesOrder EBM.
In case non-partner link errors or business faults are in the business process execution language (BPEL) processes (where the BPEL process is creating the fault message and calling the Oracle AIA Async Error handling process), the expectation is that the ApplicationFaultData is also populated.
ApplicationFaultData is an xsd: Any field in the fault message:
Fault/FaultNotification/FaultMessage/ApplicationFaultData
The BPEL processes are expected to construct a variable of element type ApplicationFaultData defined in this xsd: http://{httphostname}:{http portname}/AIAComponents/PIPS/Communications/Schemas/OrderFailureData.xsd
The fields defined in the xsd and how they must be used are listed here.
ApplicationFaultData / OrderFailureData / OrderID
BusinessComponentID - SalesOrder / Provisioning Order / Fulfillment Order / Fulfillment Billing Order
ID - SalesOrder # / Provisioning Order # / Fulfillment Order # / Fulfillment Billing Order # (If available)
ApplicationObjectKey - If available
AlternateObjectKey - SALESORDER_ID
AlternateObjectKey - SALESORDER_NUMBER
AlternateObjectKey - SALESORDER_REVISION
AlternateObjectKey - FULFILLMENTSYSTEM_ID
Example J-2 is a sample definition.
Example J-2 Sample Definition 1
<BusinessComponentID> Order ID </BusinessComponentID>
<ID> Order# (if any)</ID>
<ApplicationObjectKey>
<ID schemeID="SALESORDER_ID"schemeAgencyID="SEBL_01">SalesOrderID</ID>
</ApplicationObjectKey>
<AlternateObjectKey>
<ID schemeID="SALESORDER_ID" schemeAgencyID="COMMON">SalesOrderCommonID</ID>
</AlternateObjectKey>
<AlternateObjectKey>
<ID schemeID="SALESORDER_NUMBER" schemeAgenyId="SEBL_01">SalesOrderNumber</ID>
</AlternateObjectKey>
<AlternateObjectKey>
<ID schemeID="SALESORDER_REVISION" schemeAgenyId="SEBL_01">SalesOrderRevision</ID>
</AlternateObjectKey>
<AlternateObjectKey>
<ID schemeID="FULFILLMENTSYSTEM_ID " schemeAgenyId="FulfillmentSystemAppID">OrderID in the Fulfillment System</ID>
</AlternateObjectKey>
ApplicationFaultData / OrderFailureData / AccountID
BusinessComponentID - CommonAccountID
ID - Account Name
ApplicationObjectKey - Siebel AccountID (required only with SalesOrder EBM)
Example J-3 is a sample definition.
Example J-3 Sample Definition 2
<BusinessComponentID schemeID="CUSTOMERPARTY_ACCOUNTID" schemeAgencyID="COMMON">AccountID</BusinessComponentID> <ID schemeID="CUSTOMERPARTY_ACCOUNTNAME" schemeAgencyID="SEBL_01">AccountName</ID> <ApplicationObjectKey> <ID schemeID="CUSTOMERPARTY_ACCOUNTID" schemeAgencyID="SEBL_01">88-878PX</ID> </ApplicationObjectKey>
ApplicationFaultData / OrderFailureData / ProductID
Information regarding the Product / Discount of the failed order line.
With an entire order failure, this can be mapped for the product corresponding to the first line item of the order.
Example J-4 is a sample definition.
ApplicationFaultData / OrderFailureData / ProcessingNumber
Job ID - String type
ApplicationFaultData / OrderFailureData / ProcessingTypeCode
Common Value of the Processing Type Code
ApplicationFaultData / OrderFailureData / ProcessingQuantity
Processing Quantity as available in the EBM
ApplicationFaultData / OrderFailureData / FailureSystemCode
System where the fault occurred - 'AIA' in case the error is internal to the ABCS or BPEL.
Target System ID in case the fault is identified from the target application system
ApplicationFaultData / OrderFailureData / FailureSubSystemCode
The code of either the subsystem or the API, where the order has failed. This is applicable with participating applications. If the fault is within Oracle AIA, the service that faulted is assumed as the subsystem of failure
ApplicationFaultData / OrderFailureData / OrderLineItemFailureDataList
This is required if you are handling faults at the line-level or if the BPEL fails while it is trying to process a particular order line.
OrderLineItemID
Structure similar to OrderID
BusinessComponentID - SalesOrder / Provisioning Order / Fulfillment Order / Fulfillment Billing Order Line IDs (if any)
ID - SalesOrder Liner # / Provisioning Order Line # / Fulfillment Order Line # / Fulfillment Billing Order Line # (if available)
ApplicationObjectKey - If available (at the Siebel CRM end at least if the LineId is not yet cross-referenced)
AlternateObjectKey - SALESORDER_LINEID (COMMON)
Example J-5 is a sample definition.
Example J-5 Sample Definition 4
<BusinessComponentID> Order Line ID </BusinessComponentID> <ID> Order Line# (if any)</ID> <ApplicationObjectKey> <ID schemeID="SALESORDER_LINEID"schemeAgencyID="SEBL_01">SalesOrderLineID</ID> </ApplicationObjectKey> <AlternateObjectKey> <ID schemeID="SALESORDER_LINEID " schemeAgencyID="COMMON"> SalesOrderLineCommonID </ID> </AlternateObjectKey>
ErrorCode
Error code associated with the failure
ErrorMessage
Error message associated with the failure
ErrorSeverity
Error severity associated with the failure
Status Context
Status context of the order line
FailureSubSystemCode
Code of the subsystem or API where the order line has failed. This is applicable with participating applications. If the fault is within Oracle AIA, the service that faulted is assumed to be the subsystem of failure.
In the Requestor ABCS Implementation services, populating the EBM_HEADER variable is typically the last step of this process and the chances of an error occurring (nonsystem fault error) is more likely during this last step.
For the nonpartner link faults or business faults, the application business connector service (ABCS) should follow the guidelines as stated in "Populating the Enriched Fault Message with Business Faults". The intention is to capture as many fields as possible here in this case. No common IDs can be available.
With system faults or composite faults, you can use the extension handler feature of the Oracle AIA Error Handling Framework to enrich the fault message.
As delivered, the system faults for the Siebel Requestor ABCS are handled by the Extension Handler - oracle.apps.aia.industry.comms.eh.AIAOrderFalloutErrorHandlerExtension.java to parse the Siebel order message and enrich the fault message (Fault/FaultNotification/FaultMessage/ApplicationFaultData) with the appropriate available data (OrderID and the AccountID).
See "Configuring Oracle AIA Processes for Error Handling and Trace Logging", Extending Error Handling and Extending Fault Messages in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information on extending error handling.