Skip Headers

Oracle XML Gateway User's Guide
Release 12.1
Part Number E12954-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Setting Up Collaborations

This chapter covers the following topics:

Setting Up New Collaborations

This section describes the setup tasks for collaboration tracking using the Collaboration History feature. It is intended for Oracle E-Business Suite application product teams, or other skilled implementers interested in implementing history tracking for a new collaboration. Using this section, you can design the tracking mechanism of a collaboration and then implement it.

To implement collaboration tracking:

  1. Designing the Collaboration

  2. Creating Message Maps

  3. Setting Up FND Lookup Codes and Messages

  4. Setting Up Collaboration Events and Collaboration Final Events

  5. Adding the Workflow Events

  6. Implementing Notification Processing for New Collaborations

  7. Setting Up Trading Partners and Confirmation Messages

  8. Defining Profile Options

  9. Troubleshooting and Debugging Collaboration History

Use the Collaboration Setup Worksheet provided in Appendix H to design the collaboration.

Designing the Collaboration

When designing the collaboration, determine the information needed by the end user to evaluate the status of collaboration. When defining a collaboration tracking, consider the existing workflows, business events, and messages generated and used. Determine the messages to exchange and the events that trigger them. Also, determine whether there is information, such as errors or exceptions in the event, which is recorded to benefit the end user.

Review the Collaboration Detail window to identify appropriate data to capture.

Give a name to the collaboration and identify Oracle E-Business Suite application that owns it. This information displays in the Collaboration Type and Application fields in Collaboration History. Determine this information and enter it in the Collaboration Design section of the Collaboration Setup Worksheet in Appendix H.

An Exercise on Designing the Collaboration

A useful exercise in this evaluation is to draw a picture of the message flows between the application and the trading partner or other target system. Identify the payloads, the events that occur in the application before or after the payload is generated, and the points at which exceptions or errors are returned. Determine the XML message payloads to generate and use in the collaboration. This is determined during the high level design phase of a project.

In the Message Payloads section of the Collaboration Setup Worksheet, record the name of the payload that the collaboration generates and uses, including any inbound confirmation business object document whose receipt or contents are recorded in Collaboration History. Record whether the message is inbound or outbound from Oracle E-Business Suite. Record those that have already been mapped in Oracle XML Gateway and those that have not.

The next activity is to determine the events in the collaboration. Define all the events that are recorded for reference by the end user. These can reflect the business process activities as well as the XML message payload generation and usage. Following are a few examples:

An event can occur in Oracle E-Business Suite applications, Oracle XML Gateway, or in another system such as a B2B gateway. If one occurs in another system, then that system sends an OAG CONFIRM_004 BOD with the correct information.

Record the events in the sequence they occur and give each one a number and an event message, use the Events section of the Collaboration Setup Worksheet. A default message indicating the creation of a collaboration displays in the Event Message column for the first event and cannot be changed. In the FND Message ID column, the message identification number is recorded.

In the Event Location (Point) column, the options are Oracle Applications, Oracle XML Gateway, and the B2B gateway. If the event occurs in a workflow, then note it in the Workflow column. In the Message Payloads column, note the payload number identified earlier. If an event occurs prior to the creation of a payload, but is related because it is either the triggering event or a subsequent event that occurs before the message is generated, then refer to it in this event definition.

For example, Purchase Order Approval occurs prior to the creation of the PROCESS_PO OAG message in the XML Gateway. Process_PO is referred to in the Purchase Order Approval event definition.

See Adding the Workflow Events for information on the last column, CLN Event.

Creating Message Maps

At the end of this step, all the required XML Gateway Message Maps are created and the transaction type and subtype for all messages used are identified.

For each message, whether newly mapped in Oracle XML Gateway or existing, record the internal transaction type and subtype in the appropriate columns in the Oracle XML Gateway column of the Collaboration Setup Worksheet.

See Setting Up Collaboration Events and Collaboration Final Events for more information.

Setting Up FND Lookup Codes and Messages

After this step, the setup of all the FND Lookup codes and messages to enable your collaboration are completed.

Adding the FND Lookup Codes

To enable Collaboration Tracking, add entries in the FND Lookup tables. The FND Lookup Types that require additions include:

For each FND Lookup Type, the FND Lookup Type name is presented along with the information gathered in the previous steps. Use this information to create the new Lookup Code. Also, for each Lookup Type, examples that currently exist are listed.

Application ID

The name of this FND Lookup Type is CLN_APPLICATION_ID. This information is identified as the owner of the collaboration. Enter the identified application only if it does not already exist. It is used as the list of values for the column APPLICATION_ID in the A table.

Examples are Oracle Order Management and Oracle Purchasing.

Collaboration Type

The name of this FND Lookup Type is CLN_COLLABORATION_TYPE. This information is identified as Collaboration Name. If one exists with the same name, then it can be reused. It is used as the list of values for the column COLLABORATION_TYPE in the Collaboration History Header table.

Examples are Order for RosettaNet PIP3A4, Change Order for RosettaNet PIP3A7, Cancel Order for RosettaNet PIP3A8, Change Order Notification for RosettaNet PIP3A6, Planning, Forecast, Change Planning, and Change Forecast.

Collaboration Document Type

The name of this FND Lookup Type is CLN_COLLABORATION_DOC_TYPE. This is identified as Message Payloads. You can reuse a FND Lookup type name. This is the list of values for the column MESSAGE_TYPE in the Collaboration History Detail table.

Examples are Process PO, Acknowledge PO, Confirm BOD, and Change PO.

Adding the FND Messages

For all the event messages, create FND messages and record the number in the FND Message ID column in the Events section of the Collaboration Setup Worksheet. This information is used when raising the events.

Refer to Adding the Workflow Events for information.

Listing messages in the FND ensures their translation. These messages display in the Message column of the Collaboration History Details window.

Setting Up Collaboration Events and Collaboration Final Events

When this step is complete, Collaboration History recognizes all the events and final events defined.

Setting Up Collaboration Events

The activities in this step are key to raising the events. All collaboration events associated with the XML payload are set up using the Collaboration Event Definition window and existing events can be queried and new ones created.

See: Using the Collaboration Event Definitions Window.

Setting Up Collaboration Final Events

The collaboration final event is set up in Collaboration History so that it can record a final status of the overall collaboration. The final event is generally the occurrence of an inbound or outbound message in Oracle XML Gateway.

From the identified events and sequences identified, use the Collaboration Final Event Definition windows to record the final event.

See: Using the Collaboration Final Event Definitions Window.

Adding the Workflow Events

In this step, place the Collaboration History events in the locations that correspond to the defined events and event sequence. These events must be raised in the existing business workflows and the ECX workflows defined when the Oracle XML Gateway maps are built.

Following are the workflow events provided by Collaboration History:

In addition to the events recorded during the raising of the create, update, and add message events, Collaboration History also subscribes to all Oracle XML Gateway error events.

Raising Events

This section reviews where to place the events. It provides the instructions and guidance as to where they are raised. The individual collaborations have special requirements that do not fit the guidelines, but are to be satisfied.

Initial Event

The initial event can occur in any of the following situations:

An XML message's arrival on the inbound AQ initiates an event. When this occurs, since Collaboration History subscribes to Oracle XML Gateway's inbound message receive event, it is automatically recorded. In this case, the implementer does not have task.

If it is determined that the initiating event is in an existing business workflow, then raise the Collaboration History create event, oracle.apps.cln.ch.collaboration.create, at the appropriate location in the workflow. Determining the appropriate location requires knowledge of the business workflow and what the business end user is expecting to see when searching Collaboration History for their collaboration.

In the above example, the CLN Create Collaboration event is raised in the PO Approval Workflow prior to the raising of the Raise XML PO event. The PO Approval Workflow is a business workflow delivered with Oracle Purchasing.

An initiating event can occur when an outbound XML message is generated by Oracle XML Gateway. When the map between the Oracle tables and the XML message is built, an ECX Receive Workflow Process is defined. This process contains both generate and send activities. The Collaboration History Create event, oracle.apps.cln.ch.collaboration.create, is raised before the send activity.

Subsequent Events

All events after the initial event are called subsequent events. To record these subsequent events, a Collaboration History Update event, oracle.apps.cln.ch.collaboration.update, is raised.

As with the initial event, the update event can be raised in a business workflow or in the ECX Receive Workflow Process. Follow the instructions given in the initial event section, replacing the Create event for the Update.

Adding a Message Event

The last Collaboration History event, oracle.apps.cln.ch.collaboration.addmessage, records the additional information about the event that the end user may find useful. The exception messages or line level errors received from the trading partner are examples of the type of information that this event can be used to record. In both cases, there is no place to store the information that is easily accessible to a end user.

The add message events enable the recording of up to five values and there can be as many rows of information that are useful. In the values, store the information used to easily focus the source of the error or exception. For a purchase order, it can be a line number and for a forecast, it can be an item number, at a location, for a date, or period of time.

Use of this event is implemented by raising it at the line level of the post process for the inbound XML message's map. When used, the Collaboration History Update event is raised at the header level. This is typically used for an acknowledgement type XML messages from a trading partner.

The information captured when this event is raised displays on the Collaboration Event Details window.

Working with the Collaboration History Events

This section describes how to raise the Collaboration History events. It discusses the parameters required to make your collaboration more useful.

The events supplied for Collaboration History can be viewed in the Workflow Builder by loading the Collaboration History Standard Events item type. Using the drag-and-drop function, Collaboration History activities can be inserted where appropriate.

Note that some implementers or product teams have their own naming conventions for events. If this is the case, then Collaboration History can be used.

First, define your own create, update, and add message events. Then, include all the parameters needed by the Collaboration History events.

Then, in their subscriptions, call the appropriate Collaboration History Application Programming Interface (API):

Create - CLN_CH_EVENT_SUBSCRIPTION_PKG.CREATE_EVENT_SUB

Update - CLN_CH_EVENT_SUBSCRIPTION_PKG.UPDATE_EVENT_SUB

Add message - CLN_CH_EVENT_SUBSCRIPTION_PKG.ADDMESSGE_EVENT_SUB

Working with Key Parameters

Regardless of the event raised, one of the following sets of parameters is published to identify the event and linked to other events for the collaboration:

Or

Or, one or more of the following parameters:

Or

And one or more of the following:

When an event is raised, where there is an associated Oracle XML Gateway message, the XML Gateway Message ID is known. Additionally, for inbound messages, Internal Control Number is known.

The group of parameters is used if it is prior to an XML message being generated by Oracle XML Gateway. In most cases, these parameters are used if it is the initiating event from a business workflow.

The last group of parameters are APPLICATION_ID and UNIQUEID1-5. The combination of values used in each of the UNIQUE_ID parameters uniquely identify a collaboration. This is the case if the collaboration has no XML message payloads associated or they occur later in the sequence of events. If UNIQUEID1-5 parameters are chosen to identify a collaboration, then each time an event is raised in the collaboration flow, the same values in the same parameters are published. If an XML message payload is involved, then these same values are published with Internal Control Number or XML Message_ID of the XML message payloads.

In these cases, for Create Collaboration Event pass the Collaboration Type, Document Type, and Document Direction parameters along with Application ID and Unique ID1-5.

For Update Collaboration Event, pass the Document Type and Document Direction parameters.

Event: oracle.apps.cln.ch.collaboration.create

This event creates a new collaboration and records the initial event of the collaboration.

In addition to the key parameters, other required parameters are Document Number, Document Release Number, Document Revision Number, and Organization ID.

Document Number is the business document number associated with the collaboration. The business document number is typically the number that the business user recognizes, such as the purchase or customer order, or the forecast number. This value is used to query Collaboration History. It is not an internal key.

Document Release Number is required if the business document is a purchase order release.

Document Revision Number is required if the purchase order or other business document has a revision number associated.

Organization ID is always required because business document numbering in Oracle typically does not cross organizations. Organization ID helps to identify the exact business document.

The remaining values are all optional. However, when determining whether to publish these parameters, evaluate whether using them makes searching Collaboration History easier for the end user. These are:

Event Parameters

This table explains the key parameters:

Parameter Internal Name Description
Internal Control Number XMLG_INTERNAL_CONTROL_NUMBER XML Gateway generated unique number for inbound messages (INTERNAL_CONTROL_NUMBER).
XML Gateway Message ID XMLG_MESSAGE_ID XML Gateway message ID, which is unique across messages.
XML Gateway Internal Transaction Type XMLG_INTERNAL_TXN_TYPE XML Gateway internal transaction type for the message to be created.
XML Gateway Internal Transaction SubType XMLG_ INTERNAL_TXN_SUBTYPE XML Gateway internal transaction subtype for the message to be created.
Document Direction DOCUMENT_DIRECTION The direction the document is going (In or Out of the application) for the message to be created; probably - Out.
XML Gateway Document ID XMLG_DOCUMENT_ID Internal key of the primary business document such as the PO_header, SO_header internal key.
Trading Partner Type TRADING_PARTNER_TYPE Trading partner type, as defined in the XML Gateway.
Trading Partner ID TRADING_PARTNER_ID Trading partner ID, as defined in the XML Gateway.
Trading Partner Site TRADING_PARTNER_SITE Trading partner site for the trading partner, as defined in the XML Gateway.
UNIQUEID1-5 UNIQUE_ID1 to UNIQUE_ID5 Five fields that can contain information that uniquely identify the collaboration.
Document Number DOCUMENT_NO Business document number that the end user is familiar with.
Organization ID ORG_ID Oracle Organization ID for the organization that the business document is in.
Document Release Number RELEASE_NO If the business document is a Blanket Purchase Order Release, then this contains the purchase order release number.
Document Revision Number DOCUMENT_REVISION_NO If this is a document revision, then this contains the document revision number.
Partner Document Number PARTNER_DOCUMENT_NO The trading partner document number; for an inbound order, it contains the purchase order number.
Document Creation Date DOCUMENT_CREATION_DATE Date on which the Primary Business document was created; is not the date when the collaboration event was created.
Document Revision Date DOCUMENT_REVISION_DATE Date on which the Primary Business document was Revisioned; is not the date on which the collaboration event was created.
Doc Owner DOCUMENT_OWNER Internal ID of the employee that owns the document; refers to a buyer, planner, or order taker.
Application ID APPLICATION_ID Application ID
Collaboration Type COLLABORATION_TYPE Collaboration Type. It is based on the lookup type CLN_COLLABORATION_TYPE.
Document Type DOCUMENT_TYPE Document Type. It is based on the lookup type CLN_COLLABORATION_DOC_TYPE.
Initiation Date COLLABORATION_INITIATION_DATE Collaboration Initiation Date
Reference ID REFERENCE_ID Reference ID, which uniquely identifies the collaboration.

Event: oracle.apps.cln.ch.collaboration.update

This workflow event is raised to add new collaboration events to an existing collaboration.

Besides the key parameters, other required parameters are Document Number, Document Release Number, Document Revision Number, Organization ID, Doc_Status, and MSG_Text.

Document Number, Document Release Number, Document Revision Number, and Organization ID have the same description as in the Create event.

Doc_Status is the status of this event or document being recorded. Its value is either Success or Error. MSG_Text is the FND message ID column.

The remaining values are all optional. However, when determining whether to use these parameters, evaluate whether using them makes searching Collaboration History easier for the end user. These are:

Event Parameters

This table explains the key parameters:

Parameter Internal Name Description
Internal Control Number XMLG_INTERNAL_CONTROL_NUMBER XML Gateway generated unique number for inbound messages (INTERNAL_CONTROL_NUMBER).
XML Gateway Message ID XMLG_MESSAGE_ID XML Gateway message ID, which is unique across messages.
XML Gateway Internal Transaction Type XMLG_INTERNAL_TXN_TYPE XML Gateway internal transaction type for the message to be created.
XML Gateway Internal Transaction SubType XMLG_ INTERNAL_TXN_SUBTYPE XML Gateway internal transaction subtype for the message to be created.
Document Direction DOCUMENT_DIRECTION The direction the document is going (In or Out of the application) for the message to be created; probably - Out.
XML Gateway Document ID XMLG_DOCUMENT_ID Internal key of the primary business document such as the PO_Header, SO_Header internal key.
Trading Partner Type TRADING_PARTNER_TYPE Trading partner type, as defined in the XML Gateway.
Trading Partner ID TRADING_PARTNER_ID Trading partner ID, as defined in the XML Gateway.
Trading Partner Site TRADING_PARTNER_SITE Trading partner site, as defined in the XML Gateway.
UNIQUEID1-5 UNIQUE_ID1 to UNIQUE_ID5 Information that uniquely identify the collaboration.
Document Number DOCUMENT_NO Business document number that the end user is familiar with.
Organization ID ORG_ID Oracle Organization ID for the organization that the business document is in.
Document Release Number RELEASE_NO If the business document is a Blanket Purchase Order Release, then this contains the purchase order release.
Document Revision Number DOCUMENT_REVISION_NO If this is a document revision, then this contains the document revision number.
Partner Document Number PARTNER_DOCUMENT_NO Trading partner document number; for an inbound order, it contains the PO number.
msg_text MESSAGE_TEXT This will contain the FND Message ID; alternatively, a message literal can be entered, but not recommended.
Org_ref ORIGINATOR_REFERENCE Reference number used to uniquely identify the message; for example, the XML gateway unique message ID or a unique ID from the business-to-business gateway in use; the primary purpose is troubleshooting.
Doc_status DOCUMENT_STATUS Status of the event; is either SUCCESS or ERROR.
Disposition DISPOSITION Disposition of the collaboration; indicates if the collaboration is accepted or rejected by the trading partner or target system; set on the event which occurs when response is received that indicates whether it is accepted (mention why it is accepted, but the next line is rejected).
Document Creation Date DOCUMENT_CREATION_DATE Date on which the Primary Business document was created; not the date that the collaboration event was created.
Document Revision Date DOCUMENT_REVISION_DATE Date on which the Primary Business document was Revisioned; not the date that the collaboration event was created.
Doc Owner DOCUMENT_OWNER Internal ID of the employee that owns the document; refers to a buyer, planner, or order taker.
Application ID APPLICATION_ID Application ID
Document Type DOCUMENT_TYPE Document Type. It is based on the lookup type CLN_COLLABORATION_DOC_TYPE.
Reference ID REFERENCE_ID Reference ID, which uniquely identifies the collaboration.

Event: oracle.apps.cln.ch.collaboration.addmessage

This workflow event is raised to add collaboration event details for an existing collaboration event. This information can be text messages or other data useful to the business user in understanding the state of the collaboration. The rejection messages or information on changes data can be placed here.

In addition to the key parameters, Collaboration Detail ID can also be used.

The reference IDs can be used at the discretion of the implementers to improve the understanding of an end user. They can be line numbers, item numbers, and organization IDs.

Event Parameters

This table explains the key parameters:

Parameter Internal Name Description
Collaboration Detail ID COLLABORATION_DETAIL_ID Collaboration Detail ID
Internal Control Number XMLG_INTERNAL_CONTROL_NUMBER XML Gateway generated unique number for inbound messages (INTERNAL_CONTROL_NUMBER).
XML Gateway Message ID XMLG_MESSAGE_ID XML Gateway message ID, which is unique across messages.
XML Gateway Internal Transaction Type XMLG_INTERNAL_TXN_TYPE XML Gateway internal transaction type for the message to be created.
XML Gateway Internal Transaction SubType XMLG_ INTERNAL_TXN_SUBTYPE XML Gateway internal transaction subtype for the message to be created.
Document Direction DOCUMENT_DIRECTION The direction the document is going (In or Out of the application) for the message to be created; probably - Out.
XML Gateway Document ID XMLG_DOCUMENT_ID Internal key of the primary business document such as the PO_header, SO_header internal key.
Trading Partner Type TRADING_PARTNER_TYPE Trading partner type, as defined in the XML Gateway.
Trading Partner ID TRADING_PARTNER_ID Trading partner ID, as defined in the XML Gateway.
Trading Partner Site TRADING_PARTNER_SITE Trading partner site for the trading partner as defined in the XML Gateway.
UNIQUEID1-5 UNIQUE_ID1 to UNIQUE_ID5 Information that uniquely identify the collaboration.
REFERENCE_ID 1-5 REFERENCE_ID1 to REFERENCE_ID5 Information to identify the message with a location on the business document, such as a line for a purchase order, or the item or location or date for a plan.
Detail Message DETAIL_MESSAGE FND Message ID or alternatively a message literal; in most cases, it is the returned message from the trading partner.
XML Gateway Message ID XMLG_MESSAGE_ID XML Gateway Message ID, which is unique across messages.
Application ID APPLICATION_ID Application ID
Reference ID REFERENCE_ID Reference ID, which uniquely identifies the collaboration.
UniqueId1-5 UNIQUE_ID1 to UNIQUE_ID5 Fields that can contain information that uniquely identifies the collaboration.

Implementing Notification Processing for New Collaborations

Refer to Setting Up Notification Processing for New Collaborations to set up notifications and notification actions details.

Setting Up Trading Partners and Confirmation Messages

The collaborations are recorded only when a trading partner is set up to take part in the collaboration. Also, the OAG CONFIRM_BOD_004 inbound and outbound confirmation messages need to be set up in the Trading Partner Setup window.

Refer to Trading Partner Setup for details.

Setting Profile Options

To have Collaboration History work properly, the profile option CLN_ADMINISTRATOR profile option (profile category Deployment) needs to be set correctly by specifying an appropriate user role or username in the profile value in order to receive notification message when unexpected errors occur.

Notify Administrator is the default notification action for a notification.

Troubleshooting and Debugging Collaboration History

This section contains hints for debugging a collaboration. First, set up the system to record the debugging messages. The first two sections describe how to set up the profile option associated with debugging and how to read the debug file. Following are the hints on how to debug the workflow and Oracle E-Business Suite.

CLN: Debug Level (Debug Profile Category)

This profile option informs the system at what level of detail to capture the log messages in the debug log. Valid values are:

Profile Level: Site Level

Default Value: Unexpected

CLN: Debug Log Directory (Debug Profile Category)

This profile option informs the system where to place the log file. Values are a valid directory.

Profile Level: Site Level

Default Value: <None>

Reading the Debug File

Example:

25-mar-2003 01:51:50:2: ENTERING CLN_XMLG_EVENT_SUB_F

25-mar-2003 01:51:50:1: Message ID:B9AEEABDB3F68F0AE0301490C3C43581
25-mar-2003 01:51:50:1: Transaction Type:PO
25-mar-2003 01:51:50:1: Transaction Subtype:CANCEL
25-mar-2003 01:51:50:1: Direction:IN
25-mar-2003 01:51:50:2: EXITING CLN_XMLG_EVENT_SUB_F

Debugging Workflow

The Oracle Workflow debug files write into the workflow log tables. The Workflow provides user-friendly windows through which log details are viewed. For example, the events raised and parameters passed to them can be found in the Agent Activity in the Workflow Manager window of Oracle Applications Manager. Similarly, the workflow process log details can be found in the Status Monitor in the Workflow Administrator responsibility.

Refer to the Oracle Workflow User's Guide for more details.

Debugging Oracle E-Business Suite

Each Oracle E-Business Suite application has its own profile option to set the debug level.

Refer to the respective user's guides for more information.

Setting Up Notification Processing for New Collaborations

After determining the messages you plan to receive in the new collaboration, define any new notifications and then define the notification actions to perform when these notifications are raised for the new collaboration.

For detailed notification processing setup steps, see:

You do not have to define new notifications for the B2B gateway and Oracle XML Gateway, as the existing notifications for these notification sources are common to all collaborations. However, you will need additional notifications for the applications involved.

You can use the preconfigured notifications for existing collaborations as examples for creating new notifications.

Refer to Setting Up Customized Collaborations for a full list of preconfigured notifications.

Setting Up Customized Collaborations

This section explains the types of notification actions triggered upon receiving a notification message. Notification Processing enables significant customization using standard Oracle frameworks such as Workflow, PL/SQL, and Business Events. You can make changes to reflect any business rule. However, it is recommended that a skilled implementer who is familiar with these technologies be responsible for the changes.

Notify Administrator

Notify Administrator is the default notification action supplied with all preconfigured notifications.

You can specify up to 15 User/Roles in the Notification Role 1 - 15 fields. Notification is sent to all Users/Roles. If no User/Role is specified, then the administrator specified in the profile option: CLN_ADMINISTRATOR receives the notification.

E-Mail Format

E-Mail Subject: Notification from Supply Chain Trading Connector
E-Mail Content: 
Details of the Notification:
Notification :  < Notification >Notification Desc :  < Notification Desc >
Message : < Notification Message >
Details of the Business Document:
Collaboration Type : < Collaboration Type >
Application : < Application >
Organization ID : < Organization ID >
Document Number : < Document Number >
Revision Number : < Revision Number >
Release Number : < Release Number >
Please check the following collaboration in collaboration history for further details:
Collaboration ID : < Collaboration ID >

Notify Trading Partner

The Notify Trading Partner notification action sends an e-mail to the specified trading partner.

E-Mail Format

E-Mail Subject: Notification from Trading Partner
E-Mail Content: 
Notification occurred for the following collaboration at your trading partner site
Details of the Notification:
Notification :  < Notification >
Notification Desc :  < Notification Desc >
Message : < Notification Message >
Details of the Business Document:
Collaboration Type : < Collaboration Type >
Application : < Application >
Organization ID : < Organization ID >
Document Number : < Document Number >
Revision Number : < Revision Number >
Release Number : < Release Number >

Raise Business Event

The Raise Business Event notification action enables you to trigger an event to which other processes can subscribe using Oracle Business Event System.

Event name: Specify the fully qualified event name.

Note that the user interface (UI) does not validate the availability of the event. Register the specified event using the standard self-service window for registering event, which is a part of Oracle E-Business Suite.

Parameters: Up to 14 parameters - Constant values - to be passed to the business event; can be specified in PARAMETER1 to PARAMETER14.

This event receives a parameter list (wf_parameter_list_t) that contains:

Example

If IP_08 (Message Correlation Error) results in the B2B gateway, then update the status of the transaction accordingly. Additionally, there is a business requirement to update information within one of the applications involved.

To implement this, define a business event. A function that is subscribed to this business event can update the transaction. This event can have any number of subscriptions to trigger further action within one or more applications. Using the Notification Action Definition window, define an action of type Raise Business Event, with the event name specified. Any notification arriving with the notification code for which this action is defined (here IP_08), has the business event raised by notification processor with all the parameter values defined, which invokes all the subscriptions and their associated processing.

Note that the business events are generated if information is sent to all the subscribers interested in capturing the details and performing actions accordingly.

Start Workflow

The Start Workflow notification action initiate a predefined workflow using Oracle Workflow System.

Workflow Item Type: Specify the Workflow Item Type.

Workflow Process: Specify the Workflow Process name.

Define the workflow before defining the notification action, as the user interface does not validate the availability of the workflow.

Workflow will have the following attributes defined:

These attributes specify the notification details and are set while starting this workflow.

Example

According to the business rules, hold a transaction when an IP_07 (TPA Identification error) results in Oracle XML Gateway.

Define a workflow that applies the hold. The internal name of the workflow item type is TXN_HOLD and the internal name of the process is APPLY_HOLD. Then, using the Notification Action Definition window, define an action of type Start Workflow with the workflow item type as TXN_HOLD, and the workflow process as APPLY_HOLD. Any notification arriving with the notification code IP_07 (TPA Identification error) from XML Gateway triggers the workflow to start with the attribute values defined.

Call API

The Call API notification action invokes a particular API either using online or concurrent mode of execution.

Procedure Name: Specify the qualified PL/SQL procedure name.

Mode of Execution: The options available are:

Create the specified PL/SQL procedure and validate it with the specified signature before defining the notification action, as the UI does not validate the PL/SQL procedure.

Procedure Signature: The procedure must have wf_parameter_list_t as the only parameter. Parameter type is IN.

This parameter contains details about the notification. Fox example, notification code, description, and collaboration ID.

For example, business rules call for updates to the security access violation tables when an IP_10 (Security Error) results in business-to-business gateway.

You can define a PL/SQL API that updates security access violation tables. If the PL/SQL is namedCOLLABORATION_ACCESS.SECURITY_VIOLATED, then in the Notification Action Definition window define an action of type Call API with the procedure name as COLLABORATION_ACCESS.SECURITY_VIOLATED. Any notification arriving with the notification code IP_10 (Security Error) from the B2B gateway triggers the procedure.

Call API Parameters

This table describes the Call API parameters:

Parameter Name Description Parameter Value
Parameter1 Application ID Application ID to which this notification is intended.
Parameter2 Collaboration ID Collaboration ID that can uniquely identify the collaboration for which the notification has come.
Parameter3 Collaboration Type Collaboration type of the notification; for example, Order and Change Order.
Parameter4 Reference ID Application reference ID of the collaboration.
Parameter5 Trading Partner ID Trading partner ID of the notification message.
Parameter6 Header Description Description of the notification.
Parameter7 Notification Description Comma separated list of description for each notification code; value retrieved from CONFIRM.CONFIRMMSG. DESCRIPTN tag of the notification message.
Parameter8 Notification Code Comma separated list of notification codes; value retrieved from CONFIRMMSG.REASONCODE tag of the notification message.
Parameter9 Status Status: 00 for Success and 99 for Error; value retrieved from CONFIRM.STATUSLVL of the notification message.