This chapter covers the following topics:
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.
Use the Collaboration Setup Worksheet provided in Appendix H to design 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:
PROCESS_PO OAG message is used by Oracle XML Gateway.
ACKNOWLEDGE_PO message is used by Oracle XML Gateway.
The business-to-business gateway sends the message to the trading partner.
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.
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.
After this step, the setup of all the FND Lookup codes and messages to enable your collaboration are completed.
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.
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.
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.
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.
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:
When an inbound XML message arrives at the inbound Advanced Queue (AQ) and is processed by Oracle XML Gateway.
During an existing business workflow where there is an event activity, which signals the beginning of the collaboration.
When an outbound XML message is generated by Oracle XML Gateway and sent to the trading partner or third party application.
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.
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.
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
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.
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:
Partner Document Number - The business document number from the trading partner. For a purchase order, it can be the customer order number. This displays on the Collaboration Detail window.
Document Creation Date - This is the date that the business document is originally created. This displays on the Collaboration Detail window and used to search the history.
Document Revision Date - This is the date that the business document was revisioned. This displays on the Collaboration Detail window and used to search the history.
Document Owner - This is the owner of the document. This is the buyer, planner, or order taker. It contains the internal ID of the employees record.
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. |
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:
Disposition - This is the disposition of the collaboration. It can be accepted or rejected by the trading partner. The point at which this is discovered varies, but is often when an XML message is returned from the trading partner.
Partner Document Number - The business document number from the trading partner. For a PO, it is the customer order number. This displays on the Collaboration Detail window.
Document Creation Date - This is the date the business document was originally created. It displays on the Collaboration Detail window and can be used to search the history.
Document Revision Date - This is the date the business document was revisioned. It displays on the Collaboration Detail window and can be used to search the history.
Document Owner - This is the owner of the document. It is the buyer, planner, or order taker. It contains the internal ID of the employees record.
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. |
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. |
Refer to Setting Up Notification Processing for New Collaborations to set up notifications and notification actions details.
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.
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.
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.
This profile option informs the system at what level of detail to capture the log messages in the debug log. Valid values are:
Statement - Low level logging message giving maximum details.
Procedure - Logging message called upon entry and exit from a routine. An example is entering routine fdllov().
Event - High level logging message. An example of this is a user initiated Abort, beginning establishment of application security session.
Exception - Internal routine returns a failure code or exception. However, the error does not indicate a problem at the user level.
Examples: Profile ABC not found; Networking routine XYZ could not connect; Retrying; File not found (in a low-level file routine); Database error (in a low-level database routine like afupi).
Error - An error message to the user.
Examples: Entered a duplicate value for field XYZ. Invalid application username or password at the signon window. Function not available.
Unexpected - An unexpected situation occurred which indicates or causes instabilities in the runtime behavior. System Administrator will take appropriate action on it.
Examples: Out of memory, Required file not found, Data integrity error, Network integrity error, Internal error, Fatal database error.
Profile Level: Site Level
Default Value: Unexpected
This profile option informs the system where to place the log file. Values are a valid directory.
Profile Level: Site Level
Default Value: <None>
The CLN debug files are named as:
cln-<Date>-<running sequence number>.dbg
Example: cln-15-apr-2002-000015.dbg
Each line and debug message's format:
<Date><Time>: <Message>
An API entry can be:
ENTERING <package name>.<procedure/function name>.
Immediately after this, Name-Value pairs of all the parameters display.
The success and exception messages are found in the log file.
If the debug level is set to Statement, then extreme care is taken to ensure all of the information is logged.
The message sequence indicates the flow.
The exit of an API may appear as:
EXITING <package name>.<procedure/function name>
Most of the messages printed in the log are low level messages and may contain technical information.
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
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.
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.
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.
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 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 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 >
The Notify Trading Partner notification action sends an e-mail to the specified trading partner.
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 >
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:
Standard parameters - Details about the notification, such as notification code, description, and collaboration ID.
All the user specified parameters are appended to the parameter list, with PARAMETER1 to PARAMETER14 named as ATTRIBUTE1 to ATTRIBUTE14, respectively.
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.
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.
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.
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:
Online - API is processed synchronously.
Concurrent - API is submitted to the Concurrent Manager and processed asynchronously.
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.
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. |