The Item Synchronization for Suppliers solution workflow is composed of
business objects, collaboration objects, connectors, and maps. These
basic components work together to enable supply-side trading partners to
automatically add items to, update or delist items within, or withdraw items
from UCCnet(R) when item updates are made in their Enterprise Resource
Planning (ERP) applications. When an update is made in a
supplier's ERP system, item data is automatically validated, reformatted,
and sent to the UCCnet standard registry. Suppliers can also
communicate new or updated item information to subscribing trading partners
via UCCnet. Thus, enterprise data is synchronized with item data sent
outside the enterprise.
The Solution development guide describes the internal processing of the
Item Synchronization for Suppliers solution. It is intended for
programmers who design and implement workflows using the solution and who
might participate in designing customizations to this solution. It
assumes that users are experienced programmers and that they understand the
following concepts and have experience with the software associated with
them:
- Developing collaboration objects, business objects, maps, and other
related components.
- Installing, configuring, and operating the Item Synchronization for
Suppliers solution.
Programmers must also have experience with the operating systems on which
their implementations are installed.
The Solution development guide introduces the mechanics of the Item
Synchronization for Suppliers solution by first presenting sample, high-level,
step-by-step workflows of how the solution handles the following
scenarios:
For DTD support:
- ItemAdd
- Described in the section ItemAdd workflow (DTD support).
- ItemPublicationAdd
- Described in the section ItemPublicationAdd workflow. (ItemAdd and ItemPublicationAdd workflows normally
occur sequentially.)
- ItemChange
- Described in the section ItemChange workflow (DTD support).
- ItemPublicationChange
- Described in the section ItemPublicationChange workflow. (ItemChange and ItemPublicationChange workflows
normally occur sequentially.)
-
-
- ItemDelist
- Described in the section ItemDelist workflow (DTD support).
- ItemWithdrawal
- Described in the section ItemWithdrawal workflow (DTD support)
For XSD support:
- ItemAdd
- Described in the section ItemAdd workflow (XSD support).
- CatalogueItemNotification_Add
- Used only if UCCnet is not used as the data pool as described
in the section CatalogueItemNotification_Add and CatalogueItemPublication_Add workflows. (ItemAdd and CatalogueItemNotification_Add workflows
normally occur sequentially.)
- CatalogueItemPublication_Add
- Used only if UCCnet is used as the data pool as described in
the section CatalogueItemNotification_Add and CatalogueItemPublication_Add workflows (ItemAdd and CatalogueItemPublication_Add workflows normally
occur sequentially.)
- ItemChange
- Described in the section ItemChange workflow (XSD support).
- CatalogueItemNotification_Change
- Used only if UCCnet is not used as the data pool as described
in the section CatalogueItemNotification_Change and CatalogueItemPublication_Change workflow. (ItemAdd and CatalogueItemNotification_Add workflows
normally occur sequentially.)
- CatalogueItemPublication_Change
- Used only if UCCnet is used as the data pool as described in
the sectionCatalogueItemNotification_Change and CatalogueItemPublication_Change workflow (ItemAdd and CatalogueItemPublication_Add workflows normally
occur sequentially.)
- ItemDelist
- Described in the section ItemDelist workflow (XSD support).
- ItemWithdrawal
- Described in the section ItemWithdrawal workflow (XSD support).
Many steps contain links to detailed conceptual information about the
mechanics of the solution associated with those steps.
Other sections describe in detail how solution processing operates, as
follows:
- Checking that item data exists for fields required by UCCnet details how a UCCnet_ItemSync collaboration object ensures
that the business object to be passed to UCCnet contains data in all of the
fields for which UCCnet requires data.
- Using the PROCESSED_GTIN table describes how the solution populates and maintains data in
the provided PROCESSED_GTIN relational table, which permits a
UCCnet_processWorklist collaboration object to process incoming
INITIAL_ITEM_LOAD_REQUEST commands without the need to communicate with the
back-end ERP system.
- Using the audit_log table provides information on how the solution populates and
maintains data in the provided audit_log relational table, used to track
events associated with UCCnet activities to support complete end-to-end
accountability.
- Using the trading_partner table identifies how the solution maintains data in the provided
trading_partner relational table, which maintains the complete list of trading
partners.
- Retrieving worklists from UCCnet describes how the solution obtains worklists from
UCCnet.
- Using subdiagrams details the logic behind the subdiagrams contained in a
UCCnet_processWorklist collaboration object.
- Sending email describes how solution collaboration objects alert email
recipients of processing errors, and how subdiagrams within a
UCCnet_processWorklist collaboration object process email for different
processing circumstances.
- Logging describes the capabilities of various collaboration objects
to log errors.
- Tracing outlines how problems that might occur in the solution
workflow can be traced and identified.
Before you install and configure the Item Synchronization for Suppliers
solution, you must determine how you will connect to UCCnet and what message
format and protocols you will use.
Connectors
The way you connect to UCCnet determines the connector that you use to
communicate with it. If you exchange messages with UCCnet using an
AS2/EDIINT interface protocol, you can use a TPIConnector, an ISoftConnector,
or you can use WebSphere Business Integration Connect in conjunction with a
JMSConnector. Use the TPI connector if you communicate with UCCnet
through Trading Partner Interchange servers. Use the ISoftConnector if
you communicate with UCCnet through an iSoft Peer-to-Peer Agent. Use
the JMS connector if you communicate with UCCnet through WebSphere Business
Integration Connect. If you exchange messages through the UCCnet
Command Line Utility (CLU) or are testing your installation, you can use
either a JTextTPIConnector, JTextISoftConnector, or JTextJMSConnector.
Since the actual connector you use is dependent on your set up, this
documentation uses "AS2 channel connector" as a general term for any of
the TPIConnector, ISoftConnector, JMSConnector, JTextTPIConnector,
JTextISoftConnector, and JTextJMSConnector.
Messages
Messages are exchanged with UCCnet in Extensible Markup Language (XML)
documents. The XML document format and the protocol that you select for
communication with UCCnet significantly impact the way that you set up your
solution. The following options are available:
- DTD message format
- The format of the XML documents exchanged with UCCnet is defined by a
Document Type Definition (DTD). The DTD mode of operation has one
protocol available.
- Schema message format
- The format of the XML documents exchanged by UCCnet is defined by an XML
Schema Definition (XSD). The XSD mode of operation has two command
protocols available:
- CIN operation
- The supplier implements its own subscriber data pool.
Catalogue_Item_Notification (CIN) messages are sent from the supplier directly
to trading partners subscribed to the product categories.
- CIP operation
- The supplier uses UCCnet as the subscriber data pool.
Catalogue_Item (CI) messages containing additional item information that is
not included in the UCCnet registry data are sent from the supplier to
UCCnet. Catalogue_Item_Publication messages are then sent to UCCnet to
identify the subscribers to whom UCCnet needs to send CIN messages.
The information in the following sections outlines at a high level how the
Item Synchronization for Suppliers solution handles the workflows that support
the DTD-based implementations.
Refer to the Installation guide for detailed information on creating port
connections between collaboration objects and between collaboration objects
and connectors.
UCCnet_ItemSync, UCCnet_requestWorklist, UCCnet_processWorklist, and
Notify_by_eMail collaboration objects log error messages if they encounter
error situations during any stage of processing. See the section Logging for detailed information. Tracing can also be enabled
for all collaboration objects to record logical flows and data
processed. See the section Tracing for detailed information.
As information moves between collaboration objects, connectors, UCCnet, and
other part of the workflow, its format changes. Sometimes, the
information will exist as an XML message, sometimes it will be contained in a
business object. The conversion from one format to another is usually
carried out by maps, which you configure during installation.
The following workflow descriptions discuss the movement of information in
general terms. Details about how the information format changes as the
information passes between specific points in the workflow is available in the
section Maps and data handlers.
In the ItemAdd workflow, a new item is added to UCCnet. The source
of the flow is the creation of a new item in the source ERP
application. This workflow does not result in notifications being sent
to subscribed demand-side trading partners. Another workflow, detailed
in the section ItemPublicationAdd workflow, accomplishes sending these notifications.
Notes:
- Mapping of some attributes in the ItemAdd messages requires the use of
value translation tables. The IBM(R) WebSphere(R) InterChange
Server implements these tables as cross-reference relationships.
- If you are using XSD support, refer to the documentation found in ItemAdd workflow (XSD support)
The following description shows how high-level components of the IBM
WebSphere Business Integration Collaboration for UCCnet Item Synchronization
perform the ItemAdd workflow:
- A trigger from the ERP source provides the item (for example, an IDOC from
SAP) to the connector specific to that ERP. The connector then converts
the item into an application specific business object, passes it through a map
to convert it into an ItemBasic generic business object, and then passes the
ItemBasic business object to the UCCnet_ItemSync collaboration object with a
Create verb.
- The UCCnet_ItemSync collaboration object accepts the object and checks the
required fields for information as detailed in the section Checking that item data exists for fields required by UCCnet. If all required fields are complete, the
collaboration object continues processing it. Otherwise, the
collaboration object aborts the processing and sends an email, as detailed in
the section Alerting email recipients of processing errors. Assume that all fields are complete.
- The UCCnet_ItemSync collaboration object adds an entry for the new item to
the PROCESSED_GTIN table, setting the value for the withdrawn field
for this entry to N. See the section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- The UCCnet_ItemSync collaboration object adds an entry to the audit_log
table to record the ItemAdd transaction. See the section Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration objects sends the business object to
UCCnet by way of the AS2 channel connector, the AS2 channel server, and the
IBM WebSphere Business Integration Data Handler for XML. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet generates and returns a Message Disposition Notification (MDN) to
indicate that it has successfully received the ItemAdd message. See Processing Message Disposition Notifications (MDNs) for details.
- UCCnet creates a worklist containing the notification response for a
successful Item Add.
- The supplier sends a worklist request to UCCnet using the
JTextRWLConnector and the UCCnet_requestWorklist collaboration object.
See Retrieving worklists from UCCnet for more information
- UCCnet replies by sending the worklist containing the notification
response back to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the worklist,
identifies it as an ItemAdd notification, and dispatches it to its
ITEM_ADD_CHANGE subdiagram.
As a result of the ItemAdd workflow, UCCnet has recorded the new item
information. Now, the supplier's demand-side trading partners must
be made aware that the item is available. This ongoing workflow,
referred to as the ItemPublicationAdd workflow, is continued in the section ItemPublicationAdd workflow.
The information in this section describes how the high-level components of
the IBM WebSphere Business Integration Collaboration for UCCnet Item
Synchronization perform the ItemPublicationAdd workflow. In the
ItemPublicationAdd workflow, a new item that was passed to UCCnet through the
ItemAdd workflow (detailed in the section ItemAdd workflow (DTD support)) is made available to the supplier's demand-side
trading partners. The responses to the new item are processed as
well. As a result, the ItemPublicationAdd workflow is described as two
subflows:
- The subflow that makes the new item available to the supplier's
demand-side trading partners, described in the section ItemPublicationAdd subflow 1.
- The subflow that processes the demand-side trading partners'
responses to the new item, described in the section ItemPublicationAdd subflow 2.
The following description shows how the ItemPublicationAdd workflow makes a
new item available to a supplier's demand-side trading partners.
The source of the flow is the arrival of a UCCnetGBO_envelope at the
ITEM_ADD_CHANGE subdiagram of the UCCnet_processWorklist collaboration object
as a result of the ItemAdd workflow.
- The ITEM_ADD_CHANGE subdiagram configures the business object so that the
router map in the AS2 channel connector will select the correct transformation
map to convert the business object into an ItemPublicationAdd request.
See the section ITEM_ADD_CHANGE subdiagram for more information on this subdiagram.
- The subdiagram sends the business object to UCCnet by way of the AS2
channel connector, the AS2 channel server, and the IBM WebSphere Business
Integration Data Handler for XML. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet generates and returns a Message Disposition Notification (MDN) to
indicate that it has successfully received the ItemPublicationAdd
message. See Processing Message Disposition Notifications (MDNs) for details.
- UCCnet creates a worklist containing the notification response for a
successful ItemPublicationAdd.
- The supplier sends a worklist request to UCCnet using the
JTextRWLConnector and the UCCnet_requestWorklist collaboration object.
See Retrieving worklists from UCCnet for more information
- UCCnet replies by sending the worklist containing the notification
response back to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the worklist,
identifies it as a PUB_RELEASE_NEW_ITEM notification, and dispatches it to its
NEW_ITEM_PUBLICATION_REQUEST subdiagram.
As a result of this subflow of the ItemPublicationAdd workflow, a new item
is now available to a supplier's demand-side trading partners. The
next subflow of the ItemPublicationAdd workflow alerts them of the item's
existence and processes their responses.
At this point in processing, the first subflow of the ItemPublicationAdd
workflow has completed and a UCCnetGBO_envelope business object has arrived in
the NEW_ITEM_PUBLICATION_REQUEST subdiagram of the UCCnet_processWorklist
collaboration object.
The following describes how the ItemPublicationAdd workflow alerts
demand-side trading partners that a new item is available and processes their
responses:
- The NEW_ITEM_PUBLICATION_REQUEST subdiagram verifies that the GTIN value
associated with the item is in the PROCESSED_GTIN table and that the item is
not withdrawn. It then checks the trading_partner table to verify that
there are entries for the trading partner who supplies the new item, and for
the demand-side trading partners who will receive notification. See the
sections Using the PROCESSED_GTIN table and Using the trading_partner table for more information on these tables
- The subdiagram then configures the business object so that the router map
in the AS2 channel connector will select the correct transformation map to
convert the business object into an ItemPublicationAdd request.
- It then sends the business object to UCCnet by way of the AS2 channel
connector, the AS2 channel server, and the IBM WebSphere Business Integration
Data Handler for XML, and logs the notification in the audit_log table.
See Sending information from collaboration objects to UCCnet and Using the audit_log tablefor more details.
- UCCnet delivers the ItemPublicationAdd to the demand-side trading
partners. The trading partners can respond with any of the following
responses:
- AUTHORIZE
- The product information has been integrated into the demand-side trading
partner's legacy environment and the demand-side user is ready to begin
trading.
- PEND_PUBLICATION
- The demand-side trading partner is unsure about the proper action to take
on the product. The product is being studied, but no action is possible
at this time.
- REJECT_PUBLICATION
- The demand-side trading partner has no interest in the product.
- PRE_AUTHORIZATION
- The demand-side trading partner wants to begin the process of integrating
the product into its legacy environment. For example, this response can
indicate that the supplier needs to contact the demand-side user to begin the
process of determining order quantities and pricing.
- DE_AUTHORIZATION
- The demand-side trading partner has removed the product from the
assortment and wants no further updates sent for the product.
- Note:
- For this example, assume that the demand-side trading partner responds with
an AUTHORIZE response.
- UCCnet performs a compliance check on the data.
- If all the data exists in the appropriate formats, then UCCnet creates a
worklist for the supplier containing the notification response from the
demand-side trading partner.
- The supplier sends a worklist request to UCCnet using the
JTextRWLConnector and the UCCnet_requestWorklist collaboration object.
See Retrieving worklists from UCCnet for more information
- UCCnet replies by sending the worklist containing the notification
response back to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the worklist,
identifies it as an AUTHORIZE response, and dispatches it to its
AUTHORIZATION_RESPONSES subdiagram. See the section AUTHORIZATION_RESPONSES subdiagram for more information on this subdiagram.
- The AUTHORIZATION_RESPONSES subdiagram uses a Notify_by_eMail
collaboration object to send email to a predefined list of recipients.
It then logs the event in the audit_log table. See the sections AUTHORIZATION_RESPONSES subdiagram, Sending email through UCCnet_processWorklist collaboration object subdiagrams, and Using the audit_log table for more
information.
The ItemChange workflow sends updated information about an existing item to
UCCnet. The source of the flow is a change to the data of an existing
item in the ERP source application. Issuing a change does not result in
notifications being sent to subscribed demand-side trading partners.
Another workflow, detailed in the section ItemPublicationChange workflow, accomplishes sending these notifications.
Notes:
- Mapping of some attributes in the ItemChange messages requires the use of
value translation tables. The IBM WebSphere InterChange Server
implements these tables as cross-reference relationships.
- If you are using schema support, refer to the documentation found in ItemChange workflow (XSD support)
The following description shows how high-level components of the IBM
WebSphere Business Integration Collaboration for UCCnet Item Synchronization
perform the ItemChange workflow:
- A trigger from the ERP source provides the item (for example, an IDOC from
SAP) to the connector specific to that ERP. The connector then converts
the item into an application specific business object, passes it through a map
to convert it into an ItemBasic generic business object, and then passes the
ItemBasic business object to the UCCnet_ItemSync collaboration object with an
Update verb.
- The UCCnet_ItemSync collaboration object accepts the object and checks the
required fields for information as detailed in the section Checking that item data exists for fields required by UCCnet . If all required fields are complete, the
collaboration object continues processing. Otherwise, the collaboration
object aborts the processing and sends an email, as detailed in the section Alerting email recipients of processing errors. Assume that all fields are complete.
- The UCCnet_ItemSync collaboration object checks that an entry for the item
exists in the PROCESSED_GTIN table.
If the item exists in the table and the value for its withdrawn
field is N, then the collaboration object continues
processing.
If the item exists in the table and the value for its withdrawn
field is Y, then the collaboration object changes the
withdrawn field value to N, changes the
delete field value to U, changes the business object
verb to UNWITHDRAWN, and continues processing.
If the item does not exist in the table, then the collaboration object
changes the business object verb to Create and adds the item to the
PROCESSED_GTIN table, setting the entry's withdrawn field to
N.
- Note:
- Assume that the item already exists in the table and is not withdrawn.
See the section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- The UCCnet_ItemSync collaboration object adds an entry to the audit_log
table to identify the ItemChange transaction processed. See the section
Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration object sends the information in the
business object to UCCnet by way of the AS2 channel connector, AS2 channel
server, and the IBM WebSphere Business Integration Data Handler for
XML. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet generates and returns a Message Disposition Notification (MDN) to
indicate that it has successfully received the ItemChange message. See Processing Message Disposition Notifications (MDNs) for details.
- UCCnet creates a worklist containing the notification response for a
successful ItemChange.
- The supplier sends a worklist request to UCCnet using the
JTextRWLConnector and the UCCnet_requestWorklist collaboration object.
See Retrieving worklists from UCCnet for more information
- UCCnet replies by sending the worklist containing the notification
response back to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the worklist,
identifies it as an ItemChange notification, and dispatches it to its
ITEM_ADD_CHANGE subdiagram.
As a result of the ItemChange workflow, UCCnet has updated the item
information. Now, the supplier's demand-side trading partners must
be notified that updated information about the item exists. The
workflow that accomplishes this is described in the section ItemPublicationChange workflow.
The information in this section describes how the high-level components of
the IBM WebSphere Business Integration Collaboration for UCCnet Item
Synchronization perform the ItemPublicationChange workflow. In the
ItemPublicationChange workflow, updated item information that was passed to
UCCnet through the ItemChange workflow (detailed in the section ItemChange workflow (DTD support)) is made available to the supplier's demand-side
trading partners. The responses to this item information must then be
processed. As a result, the ItemPublicationChange workflow is described
as two subflows:
- The subflow that makes updated item information available to the
supplier's demand-side trading partners, described in the section ItemPublicationChange subflow 1.
- The subflow that processes the demand-side trading partners'
responses to the updated information, described in the section ItemPublicationChange subflow 2.
The following description shows how the ItemPublicationChange workflow
makes updated information available to a supplier's demand-side trading
partners. The source of the flow is the arrival of a UCCnetGBO_envelope
at the ITEM_ADD_CHANGE subdiagram of the UCCnet_processWorklist collaboration
object as a result of the ItemChange workflow.
- The ITEM_ADD_CHANGE subdiagram configures the business object so that the
router map in the AS2 channel connector will select the correct transformation
map to convert the business object into an ItemPublicationChange
request. See the section ITEM_ADD_CHANGE subdiagram for more information on this subdiagram.
- The subdiagram sends the business object to UCCnet by way of the AS2
channel connector, the AS2 channel server, and the IBM WebSphere Business
Integration Data Handler for XML. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet receives the message requesting it to publish the item to the
listed trading partners.
- UCCnet generates and returns a Message Disposition Notification (MDN) to
indicate that it has successfully received the ItemPublicationChange
message. See Processing Message Disposition Notifications (MDNs) for details.
- UCCnet creates a worklist containing a PUB_RELEASE_DATA_CHANGE
notification for a successful ItemPublicationChange.
- The supplier sends a worklist request to UCCnet using the
JTextRWLConnector and the UCCnet_requestWorklist collaboration object.
See Retrieving worklists from UCCnet for more information
- UCCnet replies by sending the worklist containing the notification
response back to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the worklist,
identifies it as a PUB_RELEASE_DATA_CHANGE notification, and dispatches it to
its NEW_ITEM_PUBLICATION_REQUEST subdiagram.
As a result of this subflow of the ItemPublicationAdd workflow, a new item
is now available to a supplier's demand-side trading partners. The
next subflow of the ItemPublicationAdd workflow alerts them of the item's
existence and processes their responses.
As a result of this subflow of the ItemPublicationChange workflow, updated
item information is now available to a supplier's demand-side trading
partners. The next subflow of the ItemPublicationChange workflow alerts
them of the updated information and processes their responses to it.
At this point in processing, the first subflow of the ItemPublicationChange
workflow has completed and a UCCnetGBO_envelope business object has arrived in
the NEW_ITEM_PUBLICATION_REQUEST subdiagram of the UCCnet_processWorklist
collaboration object.
The following description shows how the ItemPublicationChange workflow
alerts demand-side trading partners that new item information is available and
processes their responses:
- The NEW_ITEM_PUBLICATION_REQUEST subdiagram verifies that the GTIN value
associated with the item is in the PROCESSED_GTIN table and that the item is
not withdrawn. It then checks the trading_partner table to verify that
there are entries for the trading partner who supplies the new item, and for
the demand-side trading partners who will receive notification. See the
sections Using the PROCESSED_GTIN table and Using the trading_partner table for more information on these tables
- The subdiagram then configures the business object so that the router map
in the AS2 channel connector will select the correct transformation map to
convert the business object into an ItemPublicationChange request.
- It then sends the business object to UCCnet by way of the AS2 channel
connector, the AS2 channel server, and the IBM WebSphere Business Integration
Data Handler for XML, and logs the notification in the audit_log table.
See Sending information from collaboration objects to UCCnet and Using the audit_log table for more details.
- UCCnet delivers the ItemPublicationAdd to the demand-side trading
partners. The trading partners can respond with any of the following
responses:
- AUTHORIZE
- The product information has been integrated into the demand-side trading
partner's legacy environment and the demand-side user is ready to begin
trading.
- PEND_PUBLICATION
- The demand-side trading partner is unsure about the proper action to take
on the product. The product is being studied, but no action is possible
at this time.
- REJECT_PUBLICATION
- The demand-side trading partner has no interest in the product.
- PRE_AUTHORIZATION
- The demand-side trading partner wants to begin the process of integrating
the product into its legacy environment. For example, this response can
indicate that the supplier needs to contact the demand-side user to begin the
process of determining order quantities and pricing.
- DE_AUTHORIZATION
- The demand-side trading partner has removed the product from the
assortment and wants no further updates sent for the product.
- Note:
- For this example, assume that the demand-side trading partner responds with
an AUTHORIZE response.
- UCCnet performs a compliance check on the data. If all the data
exists in the appropriate formats, then UCCnet creates a worklist for the
supplier containing the notification response from the demand-side trading
partner.
- The supplier sends a worklist request to UCCnet using the
JTextRWLConnector and the UCCnet_requestWorklist collaboration object.
See Retrieving worklists from UCCnet for more information.
- UCCnet replies by sending the worklist containing the notification
response to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the worklist,
identifies it as an AUTHORIZE response, and dispatches it to its
AUTHORIZATION_RESPONSES subdiagram. See the section AUTHORIZATION_RESPONSES subdiagram for more information on this subdiagram.
- The AUTHORIZATION_RESPONSES subdiagram uses a Notify_by_eMail
collaboration object to send email to a predefined list of recipients.
It then logs the event in the audit_log table. See the sections AUTHORIZATION_RESPONSES subdiagram, Sending email through UCCnet_processWorklist collaboration object subdiagrams, and Using the audit_log table for more
information.
The ItemDelist workflow requests that UCCnet make an item in the repository
permanently unavailable. After an item has been delisted, it cannot be
returned to active trading. (To remove an item from active trading only
temporarily, issue an ItemWithdrawal, as discussed in the section ItemWithdrawal workflow (DTD support).) The source of the flow is the delist of an existing
item in the ERP source application. This workflow does not result in
notifications being sent to demand-side trading partners.
- Note:
- If you are using schema support, refer to the documentation found in ItemDelist workflow (XSD support)
The following description shows how high-level components of the IBM
WebSphere Business Integration Collaboration for UCCnet Item Synchronization
perform the ItemDelist workflow:
- A trigger from the ERP source provides the item (for example, an IDOC from
SAP) to the connector specific to that ERP. The connector then converts
the item into an application specific business object, passes it through a map
to convert it to an ItemBasic generic business object, and then passes the
ItemBasic business object to the UCCnet_ItemSync collaboration object with a
Delist verb.
- The UCCnet_ItemSync collaboration object accepts the object and checks the
required fields for information as detailed in the section Checking that item data exists for fields required by UCCnet. If all required fields are complete, the
collaboration object continues processing it. Otherwise, the
collaboration object aborts the processing and sends an email, as detailed in
the section Alerting email recipients of processing errors. Assume that all fields are complete.
- The UCCnet_ItemSync collaboration object removes the item from the
PROCESSED_GTIN table. See the section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- The UCCnet_ItemSync collaboration object adds an entry to the audit_log
table to identify the ItemDelist transaction processed. See the section
Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration objects sends the business object to
UCCnet by way of the AS2 channel connector, the AS2 channel server, and the
IBM WebSphere Business Integration Data Handler for XML. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet generates and returns a Message Disposition Notification (MDN) to
indicate that it has successfully received the ItemDelist message. See Processing Message Disposition Notifications (MDNs) for details.
As a result of the ItemDelist workflow, the item has been permanently
delisted in UCCnet and removed from the PROCESSED_GTIN table.
The ItemWithdrawal workflow requests that UCCnet make an item temporarily
unavailable to all or selected trading partners. For example, an item
can be temporarily removed if it is out of season or not in production.
It can also be made available to only a specific set of demand-side trading
partners as a special order item. (To remove an item from active
trading permanently, issue an ItemDelist, as discussed in the section ItemDelist workflow (DTD support).) The source of the flow is the withdrawal of an
existing item in the ERP source application. This workflow does not
result in notifications being sent to demand-side trading partners.
- Note:
- If you are using schema support, refer to the documentation found in ItemWithdrawal workflow (XSD support)
The following description shows how high-level components of the IBM
WebSphere Business Integration Collaboration for UCCnet Item Synchronization
perform the ItemWithdrawal workflow:
- A trigger from the ERP source provides the item (for example, an IDOC from
SAP) to the connector specific to that ERP. The connector then converts
the item into an application specific business object, passes it through a map
to convert it to an ItemBasic generic business object, and then passes the
ItemBasic business object to the UCCnet_ItemSync collaboration object with a
Withdraw verb.
-
The UCCnet_ItemSync collaboration object accepts the object and checks the
required fields for information as detailed in the section Checking that item data exists for fields required by UCCnet. If all required fields are complete, the
collaboration object continues processing it. Otherwise, the
collaboration object aborts the processing and sends an email, as detailed in
the section Alerting email recipients of processing errors. Assume that all fields are complete.
- The UCCnet_ItemSync collaboration object locates the item in the
PROCESSED_GTIN table and sets the value for the withdrawn field to
Y. This setting prevents an INITIAL_ITEM_LOAD_REQUEST from
causing the publication of the item. See the section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- The UCCnet_ItemSync collaboration object adds an entry to the audit_log
table to identify the ItemWithdrawal transaction processed. See the
section Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration objects sends the business object to
UCCnet by way of the AS2 channel connector, the AS2 channel server, and the
IBM WebSphere Business Integration Data Handler for XML. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet generates and returns a Message Disposition Notification (MDN) to
indicate that it has successfully received the ItemWithdrawal message.
See Processing Message Disposition Notifications (MDNs) for details.
As a result of the ItemWithdrawal workflow, the item has been temporarily
withdrawn from UCCnet and has been indicated as withdrawn in the
PROCESSED_GTIN table.
In the ItemAdd workflow, a new item is added to UCCnet. The source
of the flow is the creation of a new item in the source ERP
application. This workflow does not result in notifications being sent
to subscribed demand-side trading partners. Other workflows, detailed
in the section CatalogueItemNotification_Add and CatalogueItemPublication_Add workflows , accomplish sending these notifications.
Notes:
- Mapping of some attributes in the ItemAdd messages requires the use of
value translation tables. The IBM WebSphere InterChange Server
implements these tables as cross-reference relationships.
- If you are using DTD support, refer to the documentation found in ItemAdd workflow (DTD support).
The following description shows how high-level components of the IBM
WebSphere Business Integration Collaboration for UCCnet Item Synchronization
perform the ItemAdd workflow:
- A trigger from the ERP source provides the item (for example, an IDOC from
SAP) to the connector specific to that ERP. The connector converts the
item into an application specific business object, passes it through a map to
convert it to an ItemBasic generic business object, and then passes the
ItemBasic business object to the UCCnet_ItemSync collaboration object with a
Create verb.
- The UCCnet_ItemSync collaboration object accepts the object and checks the
required fields for information as detailed in the section Checking that item data exists for fields required by UCCnet . If all required fields are complete, the
collaboration object continues processing it. Otherwise, the
collaboration object aborts the processing and sends an email, as detailed in
the section Alerting email recipients of processing errors. Assume that all fields are complete.
- The UCCnet_ItemSync collaboration object adds an entry for the new item to
the PROCESSED_GTIN table, setting the value for the withdrawn field
for this entry to N. See the section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- The UCCnet_ItemSync collaboration object adds an entry to the audit_log
table to record the ItemAdd transaction. See the section Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration objects sends the business object to the
ItemCommandRouter collaboration object.
- The ItemCommandRouter sends the ItemBasic business object containing the
RCIR_ADD command to UCCnet by way of the AS2 channel connector and the AS2
channel server. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet sends an RCIR_ADD_RESPONSE notification to the AS2 channel server
indicating a successful item add.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Sending information from collaboration objects to UCCnet for more details.
- The UCCnet_processWorklist collaboration object receives the business
object on its From port, identifies it as an RCIR_RESPONSE notification, and
dispatches it to its RCIR_RESPONSE subdiagram.
As a result of the ItemAdd workflow, UCCnet has been updated with the new
item information. Now, the supplier's demand-side trading partners
must be made aware that the item is available. The workflow that
accomplishes this is described in the section CatalogueItemNotification_Add and CatalogueItemPublication_Add workflows.
The information in this section describes how the high-level components of
the IBM WebSphere Business Integration Collaboration for UCCnet Item
Synchronization perform the CatalogueItemNotification_Add and
CatalogueItemPublication_Add workflows. In these workflows, a new item
that was passed to UCCnet through the ItemAdd workflow (detailed in the
section ItemAdd workflow (XSD support)) is made available to the supplier's demand-side
trading partners. The demand-side trading partners' responses to
the new item are processed as well.
When this workflow begins, the ItemAdd workflow has completed and a
UCCnetGBO_envelope business object has arrived in the RCIR_RESPONSE subdiagram
of the UCCnet_processWorklist collaboration object.
- The RCIR_RESPONSE subdiagram receives the business object and logs the
notification in the audit_log table. See the section Using the audit_log table for more information on the audit_log table.
- The subdiagram creates an empty ItemBasic business object and sends it out
the DestinationAppRetrieve port with a retrieve verb.
- A completed ItemBasic object is returned on the same port with a Create
verb. This ItemBasic business object is the same one that initiated the
RCIR command, which was sent to UCCnet in the ItemAdd workflow.
-
When using a supplier-implemented data source pool (CIN
operation)
- The subdiagram sends the ItemBasic business object out the RCIR_RESPONSE
port to the CIN_CIP_Dispatcher collaboration object.
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port and maps it to a
CatalogueItemNotification_ADD UCCnetGBO_envelope business object.
- It uses the category code from the business object to retrieve the GLNs of
any trading partners that subscribe to the category. The GLN
information is taken from the GLN subscription file determined by the
DISPATCHER_GLN_FILE property.
- For each GLN found in the subscription file, the collaboration object
sends a CatalogueItemNotification_ADD (CIN_ADD) notification to the AS2
channel connector for delivery to UCCnet. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet receives the CIN_ADD notifications as XML messages and forwards
them to the demand-side trading partners.
When using UCCnet as the data source pool (CIP operation)
- The subdiagram sends the ItemBasic business object out the RCIR_RESPONSE
port to a second instance of the AS2 channel connector where it is mapped to a
PublicationCommand CatalogueItem_ADD and sent to UCCnet by way of the AS2
channel server. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet receives the CI_ADD request and returns a CatalogueItem response
notification to the AS2 channel server.
- The AS2 channel server delivers the response to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object, identifies the returned
business object as a CI response notification, and sends it to the
PUBLICATION_COMMAND_RESPONSE subdiagram of the UCCnet_processWorklist
collaboration object.
- The subdiagram creates an empty ItemBasic business object and sends it to
the DestinationAppRetrieve port with a retrieve verb. An ItemBasic
business object with a Create verb is returned on the same port. This
ItemBasic business object is the same one that initiated the RCIR command,
which was sent to UCCnet in the ItemAdd workflow.
- The subdiagram sends the business object to the CIN_CIP_Dispatcher
collaboration object.
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port and maps it to a CatalogueItemPublication_ADD
UCCnetGBO_envelope business object.
- It uses the category code from the business object to retrieve the GLNs of
any trading partners that subscribe to the category from the GLN subscription
file, defined by the DISPATCHER_GLN_FILE property.
- For each GLN that the CIN_CIP_Dispatcher collaboration object finds in the
subscription file, it sends a CatalogueItemPublication_ADD (CIP_ADD)
notification to the AS2 channel connector for delivery to UCCnet. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet sends out a CatalogueItemNotification to each subscribing
demand-side trading partner for whom a CIP was received.
- UCCnet returns a CatalogueItemPublication response to the AS2 channel
server.
- The AS2 channel server delivers the response to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the business
object, identifies it as a CIP response notification, and sends it to the
PUBLICATION_COMMAND_RESPONSE subdiagram of the UCCnet_processWorklist
collaboration object.
- The PUBLICATION_COMMAND_RESPONSE subdiagram sends the business object to a
Notify_by_eMail collaboration object with a Create verb to send a notification
email to the supplier. See PUBLICATION_COMMAND_RESPONSE subdiagram for more information on this subdiagram.
- At this point, the trading partners can respond to UCCnet with any of the
following Catalogue Item Confirmation responses:
- REVIEW
- The retailer is reviewing the item.
- REJECTED
- The retailer has rejected the item. No additional information is
requested at this time.
- ACCEPTED
- The retailer has accepted the item, but has not yet synchronized
it. This state is similar to the DTD-based PRE-AUTHORIZATION
state.
- SYNCHRONISED
- The retailer has accepted the item and synchronized it. This state
is similar to a DTD-based AUTHORIZE state.
The rest of this example assumes that a demand-side trading partner has
responded with a SYNCHRONISED response.
- UCCnet performs a compliance check on the data. If all the data
exists in the appropriate format UCCnet creates a worklist for the supplier
containing this notification response from the demand-side trading
partner.
- The supplier sends a worklist request to UCCnet using the
JTextRWLConnector and the UCCnet_requestWorklist collaboration object.
See Retrieving worklists from UCCnet for more information
- UCCnet replies by sending the worklist containing the notification
response back to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the response,
identifies it as a CATALOGUE_ITEM_CONFIRMATION response, and dispatches it to
its CATALOGUE_ITEM_CONFIRMATION subdiagram.
- The CATALOGUE_ITEM_CONFIRMATION subdiagram uses a Notify_by_eMail
collaboration object to send email to a predefined list of recipients.
It then logs the event in the audit_log table. See the sections CATALOGUE_ITEM_CONFIRMATION subdiagram, Sending email through UCCnet_processWorklist collaboration object subdiagrams, and Using the audit_log table for more
information.
The ItemChange workflow sends updated information about an existing item to
UCCnet. The source of the flow is a change to the data of an existing
item in the ERP source application. Issuing a change does not result in
notifications being sent to subscribed demand-side trading partners.
Other workflows, detailed in the section CatalogueItemNotification_Change and CatalogueItemPublication_Change workflow , accomplish sending these notifications.
Notes:
- Mapping of some attributes in the ItemChange messages requires the use of
value translation tables. The IBM WebSphere InterChange Server
implements these tables as cross-reference relationships.
- If you are not using schema support, refer to the documentation found in ItemChange workflow (DTD support).
The following description shows how high-level components of the IBM
WebSphere Business Integration Collaboration for UCCnet Item Synchronization
perform the ItemChange workflow:
- A trigger from the ERP source provides the item (for example, an IDOC from
SAP) to the connector specific to that ERP. The connector converts the
item into an application specific business object (ASBO), passes it through a
map to convert it to an ItemBasic generic business object (GBO), and then
passes this ItemBasic business object to the UCCnet_ItemSynch collaboration
object with an Update verb.
- The UCCnet_ItemSync collaboration object accepts the object and checks the
required fields for information as detailed in the section Checking that item data exists for fields required by UCCnet . If all required fields are complete, the
collaboration object continues processing it. Otherwise, the
collaboration object aborts the processing and sends an email, as detailed in
the section Alerting email recipients of processing errors. Assume that all fields are complete.
- The UCCnet_ItemSync collaboration object checks that an entry for the item
exists in the PROCESSED_GTIN table.
If the item exists in the table and the value for its withdrawn
field is N, then the collaboration object continues
processing.
If the item exists in the table and the value for its withdrawn
field is Y, then the collaboration object changes the
withdrawn field value to N, changes the
delete field value to U, changes the business object
verb to Unwithdrawn, and continues processing.
If the item does not exist in the table, then the collaboration object
changes the business object verb to Create and adds the item to the
PROCESSED_GTIN table, setting the entry's withdrawn field to
N.
- Note:
- Assume that the item already exists in the table and is not withdrawn.
See the section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- The UCCnet_ItemSync collaboration object adds an entry to the audit_log
table to identify the ItemChange transaction processed. See the section
Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration object sends the business to the
ItemCommandRouter collaboration object.
- The ItemCommandRouter collaboration sends the ItemBasic business object
containing the RCIR_CHANGE command to UCCnet by way of the AS2 channel
connector and the AS2 channel server. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet sends an RCIR_CHANGE_RESPONSE notification to the AS2 channel
server indicating a successful item change.
- The AS2 channel server delivers the response to the AS2 channel connector,
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the business
object, identifies it as a RCIR_CHANGE_RESPONSE notification, and dispatches
it to its RCIR_RESPONSE subdiagram.
As a result of the ItemChange workflow, UCCnet has been updated with the
new item information. Now, the supplier's demand-side trading
partners must be notified that the item information is available. The
workflows that accomplish this are detailed in the sectionCatalogueItemNotification_Change and CatalogueItemPublication_Change workflow.
The information in this section describes how the high-level components of
the IBM WebSphere Business Integration Collaboration for UCCnet Item
Synchronization perform the CatalogueItemNotification_Change and
CatalogueItemPublication_Change workflows. In these workflows, updated
item information that was passed to UCCnet through the ItemChange workflow
(detailed in the section ItemChange workflow (XSD support)) is made available to the supplier's demand-side
trading partners. The demand-side trading partners' responses to
this item information must then be processed.
When this workflow begins, the ItemChange workflow has completed and a
UCCnetGBO_envelope business object has arrived in the RCIR_RESPONSE subdiagram
of the UCCnet_processWorklist collaboration object.
-
The RCIR_RESPONSE subdiagram receives the business object and logs the
notification in the audit_log table. See the section Using the audit_log table for more information on the audit_log table.
- The subdiagram creates an empty ItemBasic business object and sends it out
the DestinationAppRetrieve port with a retrieve verb.
- A completed ItemBasic object is returned on the same port with an Update
verb. This ItemBasic business object is the same as the one that
initiated the corresponding RCIR command which was sent to UCCnet.
-
When using a supplier-implemented data source pool (CIN
operation)
- The subdiagram sends the ItemBasic business object out the RCIR_RESPONSE
port to the CIN_CIP_Dispatcher collaboration object.
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port and maps it to a
CatalogueItemNotification_CHANGE UCCnetGBO_envelope business object.
- It uses the category code from the business object to retrieve the GLNs of
any trading partners that subscribe to the category. The GLN
information is taken from the GLN subscription file determined by the
DISPATCHER_GLN_FILE property.
- For each GLN found in the subscription file, the collaboration object
sends a CatalogueItemNotification_CHANGE (CIN_CHANGE) notification to the AS2
channel connector for delivery to UCCnet. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet receives the CIN_CHANGE notifications as XML messages and forwards
them to the demand-side trading partners.
When using UCCnet as the data source pool (CIP operation)
- The subdiagram sends the ItemBasic business object out the RCIR_RESPONSE
port to a second instance of the AS2 channel connector where it is mapped to a
PublicationCommand CatalogueItem_CHANGE and sent to UCCnet by way of the AS2
channel server. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet receives the CI_Change request and returns a CatalogueItem response
notification to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector,
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object, identifies the returned
business object as a CI response notification, and sends it to the
PUBLICATION_COMMAND_RESPONSE subdiagram of the UCCnet_processWorklist
collaboration object.
- The subdiagram creates an empty ItemBasic business object and sends it to
the DestinationAppRetrieve port with a Retrieve verb. An ItemBasic
business object with an Update verb is returned on the same port. This
ItemBasic business object is the same one that initiated the RCIR command,
which was sent to UCCnet in the ItemChange workflow.
- The subdiagram sends the business object to a Notify_by_eMail
collaboration object in order to initiate the sending of a notification email
to the suppliers.
- The list of demand-side trading partners to receive a notification is
determined by UCCnet based on the CatalogueItemPublication (CIP) requests sent
to UCCnet when the catalogue item was originally added. UCCnet sends
out a CatalogueItemNotification to each subscribing demand-side trading
partner for whom a CIP was previously received.
-
At this point, the trading partners can respond with any of the following
Catalogue Item Confirmation responses:
- REVIEW
- The retailer is reviewing the item.
- REJECTED
- The retailer has rejected the item. No additional information is
requested at this time.
- ACCEPTED
- The retailer has accepted the item, but has not yet synchronized
it. This state is similar to the DTD-based PRE-AUTHORIZATION
state.
- SYNCHRONISED
- The retailer has accepted the item and synchronized it. This state
is similar to a DTD-based AUTHORIZE state.
The rest of this example assumes that a demand-side trading partner has
responded with a SYNCHRONISED response.
- UCCnet performs a compliance check on the data. If all the data
exists in the appropriate format, then UCCnet creates a worklist for the
supplier containing the SYNCHRONISED notification response from the
demand-side trading partner.
- The supplier sends a worklist request to UCCnet using the
JTextRWLConnector and the UCCnet_requestWorklist collaboration object.
See Retrieving worklists from UCCnet for more information
- UCCnet replies by sending the worklist containing the notification
response back to the AS2 channel server.
- The AS2 channel server delivers the worklist to the AS2 channel connector
which transforms it into a UCCnetGBO_envelope business object and delivers it
to the UCCnet_processWorklist collaboration object. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the worklist,
identifies it as a CATALOGUE_ITEM_CONFIRMATION response, and dispatches it to
its CATALOGUE_ITEM_CONFIRMATION subdiagram.
- The CATALOGUE_ITEM_CONFIRMATION subdiagram uses a Notify_by_eMail
collaboration object to send email to a predefined list of recipients.
It then logs the event in the audit_log table. See the sections CATALOGUE_ITEM_CONFIRMATION subdiagram, Sending email through UCCnet_processWorklist collaboration object subdiagrams, and Using the audit_log table for more
information.
The ItemDelist workflow requests that UCCnet make an item in the repository
permanently unavailable. After an item has been delisted, it cannot be
returned to active trading. (To remove an item from active trading only
temporarily, issue an ItemWithdrawal, as discussed in the section ItemWithdrawal workflow (XSD support).) The source of the flow is the delist of an existing
item in the ERP source application. This workflow does not result in
notifications being sent to demand-side trading partners.
- Note:
- If you are not using schema support, refer to the documentation found in ItemDelist workflow (DTD support)
The following description shows how high-level components of the IBM
WebSphere Business Integration Collaboration for UCCnet Item Synchronization
perform the ItemDelist workflow:
- A trigger from the ERP source provides the item (for example, an IDOC from
SAP) to the connector specific to that ERP. The connector converts the
item into an application specific business object, and passes it through a map
to convert it to an ItemBasic generic business object, and then passes the
ItemBasic business object to the UCCnet_ItemSync collaboration object with a
Delist verb.
- The UCCnet_ItemSync collaboration object accepts the object and checks the
required fields for information as detailed in the section Checking that item data exists for fields required by UCCnet. If all required fields are complete, the
collaboration object continues processing it. Otherwise, the
collaboration object aborts the processing and sends an email, as detailed in
the section Alerting email recipients of processing errors. Assume that all fields are complete.
- The UCCnet_ItemSync collaboration object removes the item from the
PROCESSED_GTIN table. See the section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- The UCCnet_ItemSync collaboration object adds an entry to the audit_log
table to identify the ItemDelist transaction processed. See the section
Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration object sends the ItemBasic business
object to the ItemCommandRouter collaboration object.
- The ItemCommandRouter determines that the received business object is a
delist.
-
When using a supplier-implemented data source pool (CIN
operation)
- The ItemCommandRouter sends the ItemBasic business object out the ToCIN_CI
port to a CIN_CIP_Dispatcher collaboration object.
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port and maps it to a
CatalogueItemNotification_DELIST UCCnetGBO_envelope business object.
- It uses the category code from the business object to retrieve the GLNs of
any trading partners that subscribe to the category. The GLN
information is taken from the GLN subscription file determined by the
CIN_DISPATCHER_GLN_FILE property.
- For each GLN found in the subscription file, the collaboration object
sends a CatalogueItemNotification_DELIST (CIN_DELIST) notification to the AS2
channel connector to be delivered to UCCnet. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet generates an MDN to indicate successful receipt of the
CatalogueItemNotification_DELIST message. See Processing Message Disposition Notifications (MDNs) for details.
When using UCCnet as the data source pool (CIP operation)
- The ItemCommandRouter sends the ItemBasic business object out the ToCIN_CI
port to the Notify_by_eMail collaboration object.
- The Notify_by_eMail collaboration object sends a note to the supplier,
indicating that CI_DELIST is unsupported.
As a result of the ItemDelist workflow, the item has been permanently
delisted in UCCnet and removed from the PROCESSED_GTIN table.
The ItemWithdrawal workflow requests that UCCnet make an item temporarily
unavailable to all or selected trading partners. An item might be
temporarily removed, for instance, if it is out of season or not in
production. It might also be made available only to a specific set of
demand-side trading partners as a special order item. (To remove an
item from active trading permanently, issue an ItemDelist, as discussed in the
section ItemDelist workflow (XSD support).) The source of the flow is the withdrawal of an
existing item in the ERP source application. This workflow does not
result in notifications being sent to demand-side trading partners.
- Note:
- If you are not using schema support, refer to the documentation found in ItemWithdrawal workflow (DTD support)
The following description shows how high-level components of the IBM
WebSphere Business Integration Collaboration for UCCnet Item Synchronization
perform the ItemWithdrawal workflow:
-
A trigger from the ERP source provides the item (for example, an IDOC from
SAP) to the connector specific to that ERP. The connector converts item
into an application specific business object, and passes it through a map to
convert it to an ItemBasic generic business object, and then passes the
ItemBasic business object to the UCCnet_ItemSync collaboration object with a
Withdraw verb.
- The UCCnet_ItemSync collaboration object accepts the object and checks the
required fields for information as detailed in the section Checking that item data exists for fields required by UCCnet. If all required fields are complete, the
collaboration object continues processing it. Otherwise, the
collaboration object aborts the processing and sends an email, as detailed in
the section Alerting email recipients of processing errors. Assume that all fields are complete.
- The UCCnet_ItemSync collaboration object changes the Withdrawn column in
the PROCESSED_GTIN table to a value of Y. See the section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- The UCCnet_ItemSync collaboration object adds an entry to the audit_log
table to identify the ItemWithdawal transaction processed. See the
section Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration object sends the ItemBasic business
object to the ItemCommandRouter collaboration object.
- The ItemCommandRouter collaboration object determines from the business
object's verb and the DeleteFlag value that the item is being
withdrawn.
-
When using a supplier-implemented data source pool (CIN
operation)
- The ItemCommandRouter sends the ItemBasic business object out the ToCIN_CI
port to a CIN_CIP_Dispatcher collaboration object.
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port and maps it to a
CatalogueItemNotification_WITHDRAW UCCnetGBO_envelope business object.
- It uses the category code from the business object to retrieve the GLNs of
any trading partners that subscribe to the category. The GLN
information is taken from the GLN subscription file determined by the
CIN_DISPATCHER_GLN_FILE property.
- For each GLN found in the subscription file, the collaboration object
sends a CatalogueItemNotification_WITHDRAW (CIN_WITHDRAW) notification to the
AS2 channel connector to be delivered to UCCnet. See Sending information from collaboration objects to UCCnet for more details.
- UCCnet generates an MDN to indicate successful receipt of the
CatalogueItemNotification_WITHDRAW message. See Processing Message Disposition Notifications (MDNs) for details.
When using UCCnet as the data source pool (CIP operation)
- The ItemCommandRouter sends the ItemBasic business object out the ToCIN_CI
port to a Notify_by_eMail collaboration object.
- The Notify_by_eMail collaboration object receives the business object and
sends a note to the supplier saying that the CI_WITHDRAW is
unsupported.
As a result of the ItemWithdrawal workflow, the item has been temporarily
withdrawn from UCCnet and has been indicated as withdrawn in the
PROCESSED_GTIN table.
As the data flows through the workflows, the form of the information
changes. Sometimes it is stored in a generic business object, sometimes
in an application specific business object, and sometimes, the data is
contained in an XML message. As part of the processing, data passes
through a variety of transformations. Normally, these transformations
are done to prepare the data for the next step in the workflow, whether it be
a collaboration object, a connector, or the AS2 channel server.
The following tables detail how the format of the information changes as it
moves between the connectors, collaboration objects, and other parts that make
up a workflow. The Transform initiator and Time
initiated columns indicate the connector or collaboration object that
initiated the data transform, and the point in the workflow that it does
this. The Input and Output columns respectively
indicate the format of the data before and after the transformation takes
place. The Transformer column indicates the map or data
handler used to carry out the transformation.
Table 1. Transformers used for DTD Support using ISoft connectivity
The following table indicates how the format of information changes as
it moves between parts of a workflow. It also indicates what
transformers are used to accomplish these changes. Information for the
iSoft Connector controller and iSoft Connector agent is also applicable for
the JTextISoft Connector controller and JTextISoft Connector agent.
|
Transform initiator
| Time initiated
| Input
| Output
| Transformer
|
iSoft Connector controller
| Sending information to UCCnet
| ItemBasic generic business object (GBO)
| UCCnetDTD_envelope application specific business object (ASBO)
| RouterMap_CwItemBasic_to_UCCnetDTD_envelope map and the transformation
maps that it calls:
CwItemBasic_to_UCCnetDTD_envelope_documentCommand_item
CwItemBasic_to_UCCnetDTD_envelope_publishCommand_documentIdentifier
|
iSoft Connector controller
| Sending information to UCCnet
| UCCnetGBO_envelope GBO
| UCCnetDTD_envelope ASBO
| RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope map and the
transformation maps that it calls:
UCCnetGBO_envelope_to_UCCnetDTD_envelope
UCCnetGBO_envelope_notification_to_UCCnetDTD_envelope_publishCommand
|
iSoft Connector controller
| Receiving information from UCCnet
| UCCnetDTD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetDTD_envelope_to_UCCnetGBO_envelope map
|
iSoft Connector agent
| Receiving information from UCCnet
| XML message in UCCnet format
| UCCnetDTD_envelope ASBO
| IBM WebSphere Business Integration DataHandler for XML
|
iSoft Connector agent
| Sending information to UCCnet
| UCCnetDTD_envelope ASBO
| XML message in UCCnet format
| IBM WebSphere Business Integration DataHandler for XML
|
SAP connector controller (ERP specific connector in the example
workflows)
| Receiving item information from SAP application
| SAP ASBO
| ItemBasic GBO
| Sa4CwItemBasic map
|
SAP Connector controller (ERP specific connector in the example
workflows)
| Sending item information to SAP application
| ItemBasic GBO
| SAP ASBO
| CwSa4ItemBasic map
|
JTextRWLConnector agent
| Initiating request for UCCnet to return a worklist
| XML message in UCCnet format
| UCCnetDTD_envelope ASBO
| IBM WebSphere Business Integration Data Handler for XML
|
JTextRWLConnector controller
| Initiating request for UCCnet to return a worklist
| UCCnetDTD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetDTD_envelope_to_UCCnetGBO_envelope map
|
Table 2. Transformers used for DTD Support using TPI connectivity
The following table indicates how the format of information changes as
it moves between parts of a workflow. It also indicates what
transformers are used to accomplish these changes. Information for the
TPI Connector controller and TPI Connector agent is also applicable for the
JTextTPI Connector controller and JTextTPI Connector agent.
|
Transform initiator
| Time initiated
| Input
| Output
| Transformer
|
TPI Connector controller
| Sending information to UCCnet
| ItemBasic generic business object (GBO)
| UCCnetTPIDTD_envelope application specific business object (ASBO)
| RouterMap_CwItemBasic_to_UCCnetTPIDTD_envelope map and the transformation
maps that it calls:
CwItemBasic_to_UCCnetTPIDTD_envelope_documentCommand_item
CwItemBasic_to_UCCnetTPIDTD_envelope_publishCommand_documentIdentifier
|
iSoft Connector controller
| Sending information to UCCnet
| UCCnetGBO_envelope GBO
| UCCnetTPIDTD_envelope ASBO
| RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope map and the
transformation maps that it calls:
UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope
UCCnetGBO_envelope_notification_to_UCCnetTPIDTD_envelope_publishCommand
|
TPI Connector controller
| Receiving information from UCCnet
| UCCnetTPIDTD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope map
|
TPI Connector agent
| Receiving information from UCCnet
| XML message in UCCnet format
| UCCnetTPIDTD_envelope ASBO
| IBM WebSphere Business Integration DataHandler for XML
|
TPI Connector agent
| Sending information to UCCnet
| UCCnetTPIDTD_envelope ASBO
| XML message in UCCnet format
| IBM WebSphere Business Integration DataHandler for XML
|
SAP connector controller (ERP specific connector in the example
workflows)
| Receiving item information from SAP application
| SAP ASBO
| ItemBasic GBO
| Sa4CwItemBasic map
|
SAP Connector controller (ERP specific connector in the example
workflows)
| Sending item information to SAP application
| ItemBasic GBO
| SAP ASBO
| CwSa4ItemBasic map
|
JTextRWLConnector agent
| Initiating request for UCCnet to return a worklist
| XML message in UCCnet format
| UCCnetTPIDTD_envelope ASBO
| IBM WebSphere Business Integration Data Handler for XML
|
JTextRWLConnector controller
| Initiating request for UCCnet to return a worklist
| UCCnetTPIDTD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope map
|
Table 3. Transformers used for DTD Support using WebSphere Business Integration Connect
The following table indicates how the format of information changes as
it moves between parts of a workflow. It also indicates what
transformers are used to accomplish these changes. Information for the
JMS Connector controller and JMS Connector agent is also applicable for the
JTextJMS Connector controller and JTextJMS Connector agent.
|
Transform initiator
| Time initiated
| Input
| Output
| Transformer
|
JMS Connector controller
| Sending information to UCCnet
| ItemBasic generic business object (GBO)
| UCCnetJMSDTD_envelope application specific business object (ASBO)
| RouterMap_CwItemBasic_to_UCCnetJMSDTD_envelope map and the transformation
maps that it calls:
CwItemBasic_to_UCCnetJMSDTD_envelope_documentCommand_item
CwItemBasic_to_UCCnetJMSDTD_envelope_publishCommand_documentIdentifier
|
JMS Connector controller
| Sending information to UCCnet
| UCCnetGBO_envelope GBO
| UCCnetJMSDTD_envelope ASBO
| RouterMap_UCCnetGBO_envelope_to_UCCnetJMSDTD_envelope map and the
transformation maps that it calls:
UCCnetGBO_envelope_to_UCCnetJMSDTD_envelope
UCCnetGBO_envelope_notification_to_UCCnetJMSDTD_envelope_publishCommand
|
JMS Connector controller
| Receiving information from UCCnet
| UCCnetJMSDTD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetJMSDTD_envelope_to_UCCnetGBO_envelope map
|
JMS Connector agent
| Receiving information from UCCnet
| XML message in UCCnet format
| UCCnetJMSDTD_envelope ASBO
| IBM WebSphere Business Integration DataHandler for XML
|
JMS Connector agent
| Sending information to UCCnet
| UCCnetJMSDTD_envelope ASBO
| XML message in UCCnet format
| IBM WebSphere Business Integration DataHandler for XML
|
SAP connector controller (ERP specific connector in the example
workflows)
| Receiving item information from SAP application
| SAP ASBO
| ItemBasic GBO
| Sa4CwItemBasic map
|
SAP Connector controller (ERP specific connector in the example
workflows)
| Sending item information to SAP application
| ItemBasic GBO
| SAP ASBO
| CwSa4ItemBasic map
|
JTextRWLConnector agent
| Initiating request for UCCnet to return a worklist
| XML message in UCCnet format
| UCCnetJMSDTD_envelope ASBO
| IBM WebSphere Business Integration Data Handler for XML
|
JTextRWLConnector controller
| Initiating request for UCCnet to return a worklist
| UCCnetJMSDTD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetJMSDTD_envelope_to_UCCnetGBO_envelope map
|
Table 4. Transformers used for XSD support using iSoft connectivity
The following table indicates how the format of information changes as
it moves between parts of a workflow. It also indicates what
transformers are used to accomplish these changes. Information for the
iSoft Connector controller and iSoft Connector agent is also applicable for
the JTextISoft Connector controller and JTextISoft Connector agent.
|
Transform initiator
| Time initiated
| Input
| Output
| Transformer
|
iSoft Connector controller
| Sending information to UCCnet in ItemAdd and ItemChange workflows
| ItemBasic generic business object (GBO)
| UCCnetXSD_envelope application specific business object (ASBO)
|
- CIN operation
- CwItemBasic_to_UCCnetXSD_envelope_registerCommand_itemAddChange map
- CIP operation
- CwItemBasic_to_UCCnetXSD_envelope_registerCommand_CIP_itemAddChange map
|
iSoft Connector controller (second instance)
| Sending information to UCCnet in ItemPublication and ItemNotification
workflows
| ItemBasic GBO
| UCCnetXSD_envelope ASBO
|
- CIP operation only
- CwItemBasic_to_UCCnetXSD_envelope_publicationCommand_catalogueItem map
|
iSoft Connector controller
| Receiving information from UCCnet
| UCCnetXSD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetXSD_envelope_to_UCCnetGBO_envelope map
|
iSoft Connector controller
| Sending information to UCCnet
| UCCnetGBO_envelope GBO
| UCCnetXSD_envelope ASBO
| UCCnetGBO_envelope_to_UCCnetXSD_envelope map
|
iSoft Connector agent
| Sending information to UCCnet
| UCCnetXSD_envelope ASBO
| XML message in UCCnet format
| IBM WebSphere Business Integration DataHandler for XML
|
iSoft Connector agent
| Receiving information from UCCnet
| XML message in UCCnet format
| UCCnetXSD_envelope ASBO
| IBM WebSphere Business Integration DataHandler for XML
|
SAP connector controller (ERP specific connector in the example
workflows)
| Receiving item information from SAP application
| SAP ASBO
| ItemBasic GBO
| Sa4CwItemBasic map
|
SAP Connector controller (ERP specific connector in the example
workflows)
| Sending item information to SAP application
| ItemBasic GBO
| SAP ASBO
| CwSa4ItemBasic map
|
JTextRWLConnector Connector agent
| Initiating request for UCCnet to return a worklist
| XML message in UCCnet format
| UCCnetXSD_envelope ASBO
| IBM WebSphere Business Integration Data Handler for XML
|
JTextRWL Connector controller
| Initiating request for UCCnet to return a worklist
| UCCnetXSD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetXSD_envelope_to_UCCnetGBO_envelope map
|
CIN_CIP_Dispatcher collaboration object
| Sending CIN or CIP requests to UCCnet
| ItemBasic GBO
| UCCnetGBO_envelope GBO
|
- CIN operation
- CwItemBasic_to_UCCnetGBO_envelope_notifyCommand_catalogueItem map
- CIP operation
- CwItemBasic_to_UCCnetGBO_env_publicationCommand_catalogueItemPublication
map
|
Table 5. Transformers used for XSD support using TPI connectivity
The following table indicates how the format of information changes as
it moves between parts of a workflow. It also indicates what
transformers are used to accomplish these changes. Information for the
TPI Connector controller and TPI Connector agent is also applicable for the
JTextTPI Connector controller and JTextTPI Connector agent.
|
Transform initiator
| Time initiated
| Input
| Output
| Transformer
|
TPI Connector controller
| Sending information to UCCnet in ItemAdd and ItemChange workflows
| ItemBasic generic business object (GBO)
| UCCnetTPIXSD_envelope application specific business object (ASBO)
|
- CIN operation
- CwItemBasic_to_UCCnetTPIXSD_envelope_registerCommand_itemAddChange map
- CIP operation
- CwItemBasic_to_UCCnetTPIXSD_envelope_registerCommand_CIP_itemAddChange map
|
TPI Connector controller (second instance)
| Sending information to UCCnet in ItemPublication and ItemNotification
workflows
| ItemBasic GBO
| UCCnetTPIXSD_envelope ASBO
|
- CIP operation only
- CwItemBasic_to_UCCnetTPIXSD_envelope_publicationCommand_catalogueItem map
|
TPI Connector controller
| Receiving information from UCCnet
| UCCnetTPIXSD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope map
|
TPI Connector controller
| Sending information to UCCnet
| UCCnetGBO_envelope GBO
| UCCnetTPIXSD_envelope ASBO
| UCCnetGBO_envelope_to_UCCnetTPIXSD_envelope map
|
TPI Connector agent
| Sending information to UCCnet
| UCCnetTPIXSD_envelope ASBO
| XML message in UCCnet format
| IBM WebSphere Business Integration DataHandler for XML
|
TPI Connector agent
| Receiving information from UCCnet
| XML message in UCCnet format
| UCCnetTPIXSD_envelope ASBO
| IBM WebSphere Business Integration DataHandler for XML
|
SAP connector controller (ERP specific connector in the example
workflows)
| Receiving item information from SAP application
| SAP ASBO
| ItemBasic GBO
| Sa4CwItemBasic map
|
SAP Connector controller (ERP specific connector in the example
workflows)
| Sending item information to SAP application
| ItemBasic GBO
| SAP ASBO
| CwSa4ItemBasic map
|
JTextRWLConnector Connector agent
| Initiating request for UCCnet to return a worklist
| XML message in UCCnet format
| UCCnetTPIXSD_envelope ASBO
| IBM WebSphere Business Integration Data Handler for XML
|
JTextRWL Connector controller
| Initiating request for UCCnet to return a worklist
| UCCnetTPIXSD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope map
|
CIN_CIP_Dispatcher collaboration object
| Sending CIN or CIP requests to UCCnet
| ItemBasic GBO
| UCCnetGBO_envelope GBO
|
- CIN operation
- CwItemBasic_to_UCCnetGBO_envelope_notifyCommand_catalogueItem map
- CIP operation
- CwItemBasic_to_UCCnetGBO_env_publicationCommand_catalogueItemPublication
map
|
Table 6. Transformers used for XSD support using WebSphere Business Integration Connect
The following table indicates how the format of information changes as
it moves between parts of a workflow. It also indicates what
transformers are used to accomplish these changes. Information for the
JMS Connector controller and JMS Connector agent is also applicable for the
JTextJMS Connector controller and JTextJMS Connector agent.
|
Transform initiator
| Time initiated
| Input
| Output
| Transformer
|
JMS Connector controller
| Sending information to UCCnet in ItemAdd and ItemChange workflows
| ItemBasic generic business object (GBO)
| UCCnetJMSXSD_envelope application specific business object (ASBO)
|
- CIN operation
- CwItemBasic_to_UCCnetJMSXSD_envelope_registerCommand_itemAddChange map
- CIP operation
- CwItemBasic_to_UCCnetJMSXSD_envelope_registerCommand_CIP_itemAddChange map
|
JMS Connector controller (second instance)
| Sending information to UCCnet in ItemPublication and ItemNotification
workflows
| ItemBasic GBO
| UCCnetJMSXSD_envelope ASBO
|
- CIP operation only
- CwItemBasic_to_UCCnetJMSXSD_envelope_publicationCommand_catalogueItem map
|
TPI Connector controller
| Receiving information from UCCnet
| UCCnetJMSXSD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetJMSXSD_envelope_to_UCCnetGBO_envelope map
|
JMS Connector controller
| Sending information to UCCnet
| UCCnetGBO_envelope GBO
| UCCnetJMSXSD_envelope ASBO
| UCCnetGBO_envelope_to_UCCnetJMSXSD_envelope map
|
JMS Connector agent
| Sending information to UCCnet
| UCCnetJMSXSD_envelope ASBO
| XML message in UCCnet format
| IBM WebSphere Business Integration DataHandler for XML
|
JMS Connector agent
| Receiving information from UCCnet
| XML message in UCCnet format
| UCCnetJMSXSD_envelope ASBO
| IBM WebSphere Business Integration DataHandler for XML
|
SAP connector controller (ERP specific connector in the example
workflows)
| Receiving item information from SAP application
| SAP ASBO
| ItemBasic GBO
| Sa4CwItemBasic map
|
SAP Connector controller (ERP specific connector in the example
workflows)
| Sending item information to SAP application
| ItemBasic GBO
| SAP ASBO
| CwSa4ItemBasic map
|
JTextRWLConnector Connector agent
| Initiating request for UCCnet to return a worklist
| XML message in UCCnet format
| UCCnetJMSXSD_envelope ASBO
| IBM WebSphere Business Integration Data Handler for XML
|
JTextRWL Connector controller
| Initiating request for UCCnet to return a worklist
| UCCnetJMSXSD_envelope ASBO
| UCCnetGBO_envelope GBO
| UCCnetJMSXSD_envelope_to_UCCnetGBO_envelope map
|
CIN_CIP_Dispatcher collaboration object
| Sending CIN or CIP requests to UCCnet
| ItemBasic GBO
| UCCnetGBO_envelope GBO
|
- CIN operation
- CwItemBasic_to_UCCnetGBO_envelope_notifyCommand_catalogueItem map
- CIP operation
- CwItemBasic_to_UCCnetGBO_env_publicationCommand_catalogueItemPublication
map
|
In many of the workflows, UCCnet generates a Message Disposition
Notification to indicate that it has received a message from the
supplier. The typical processing of this MDN is as follows:
- The AS2 channel server delivers the MDN to the UCCnet_processWorklist
collaboration object by way of the IBM WebSphere Business Integration Data
Handler for XML and the AS2 channel connector. See Receiving data for a collaboration object from UCCnet for details.
- The UCCnet_processWorklist collaboration object receives the MDN inside a
generic business object and dispatches it to the SIMPLE_RESPONSE subdiagram
for further processing.
- The SIMPLE_RESPONSE subdiagram uses a Notify_by_eMail collaboration object
to send email to a predefined list of recipients. See the sections SIMPLE_RESPONSE subdiagram and Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
In many of the workflows, UCCnet generates, but does not automatically
return, a worklist containing a response to a message received from the
supplier. In these cases, the supplier must request the worklist from
UCCnet.
Retrieval of a worklist from UCCnet happens as follows:
- The supplier uses a time-triggered process to move a worklist query
command to the event directory of the JTextRWLConnector: This
movement process is not a part of the solution, and must be customized by the
supplier.
- The JTextRWLConnector polls its event directory for new query
commands at user-defined time intervals.
- When the JTextRWBConnector finds a query command in the event
directory, it sends it to the IBM WebSphere Business Integration Data Handler
for XML, which converts it to an application specific business object
(ASBO).
- The JTextRWLConnector passes the business object through a map to convert
it to a UCCnetGBO_envelope GBO and then passes it to a UCCnet_requestWorklist
collaboration object.
- The UCCnet_requestWorklist collaboration object, in turn sends the
business object to the AS2 channel connector for delivery to UCCnet.
See Sending information from collaboration objects to UCCnet for details.
The DTD_URL and SET_UNIQUE_IDS properties of the UCCnet_requestWorklist
collaboration object affect the outgoing XML message in systems using the DTD
XML definition type. The DocType line in the XML is set according to
the value of the DTD_URL property. If outgoing messages are required to
have unique message IDs, the SET_UNIQUE_IDS property must be set to ALL
Both the worklist request XML and the polling interval can be
changed. For example, the worklist query command XML message tailored
for Authorization Notifications (query type="NOTIFICATION" with
name="AUTHORIZATION_INFORMATION" and status="UNREAD") can be used to request
the worklist authorization notification contents. A similar request can
be constructed to read any dead letter notifications. As an
alternative, all notifications can be requested. The polling interval
is set in the PollFrequency attribute of the JTextRWLConnector and
is in milliseconds.
The UCCnet_requestWorklist collaboration supports the notification
type="PUBLICATION_INFORMATION" for the topics PEND_PUBLICATION,
PRE_AUTHORIZATION, AUTHORIZATION, REJECT_PUBLICATION, DE_AUTHORIZATION, and in
the notifications for NEW_ITEM_PUBLICATION_REQUEST and ITEM_INFORMATION
(ITEM_ADD, ITEM_CHANGE).
Sending messages from a collaboration object to UCCnet
In many of the workflows, a collaboration object needs to send information
to UCCnet. The following set of events accomplishes this action:
- The collaboration object sends a generic business object (GBO) to the AS2
channel connector.
- The connector controller calls the associated map configured for this GBO
to convert it into an application specific business object (ASBO).
- The connector controller passes the ASBO to the connector agent.
- The connector agent calls the IBM WebSphere Business Integration Data
Handler for XML which converts the ASBO into a UCCnet formatted XML
message.
- The AS2 channel connector agent then passes the XML message to the AS2
channel server, which creates the digest, encrypts, and transmits the message
to UCCnet.
Receiving messages back from UCCnet
In many of the workflows, UCCnet will send a message to the AS2 channel
server to be passed on to a collaboration object. The following set of
events accomplishes this action:
- UCCnet sends an XML message to the AS2 channel server.
- The AS2 channel connector agent retrieves the message from the AS2 channel
server.
- The connector agent calls the IBM WebSphere Business Integration Data
Handler for XML to convert the message into an application specific business
object (ASBO).
- The connector agent passes the ASBO to the connector controller.
- The connector controller calls the associated map configured for this ASBO
to convert it into a generic business object (GBO).
- The AS2 channel connector then passes the GBO to all collaboration objects
that subscribe to the GBO.
UCCnet requires its community of trading partners to provide standardized
item data in particular formats to its registry. As a result, UCCnet
requires requests for ItemAdd, ItemChange, ItemDelist, and ItemWithdrawal
publications to have data provided for certain fields. If the data for
the required fields is not present, UCCnet does not process the
publications. Data might be missing if the ERP does not require
information for these same fields and the ERP user is not aware of the UCCnet
requirements.
To help ensure that ItemAdd, ItemChange, ItemDelist, and ItemWithdrawal
publications are accepted by UCCnet, when a UCCnet_ItemSync collaboration
object accepts an ItemBasic business object, it checks that the following
fields that are required by UCCnet to have data contain information
(i.e., are not NULL):
- For ItemAdd and ItemChange publications:
- gtin
- dimension
- height
- volume
- productHierarchy
- barCodeId
- unitOfWgt (if either the grossWeight or netWeight fields contain values)
- For ItemDelist and ItemWithdrawal publications:
- Note:
- The UCCnet_ItemSync collaboration object checks only that the required fields
are not NULL. It does not verify that the information within them is in
the correct format for UCCnet.
If all required fields are complete, the UCCnet_ItemSync collaboration
object continues processing it. If all required fields are not
complete, the collaboration object aborts processing and sends an email
requesting the missing information to an email address provided in the
UCCnet_ItemSync collaboration object's SEND_MAIL_TO configuration
property. See the section Alerting email recipients of processing errors for more information on how email is handled within the
solution.
The PROCESSED_GTIN table is a relational table provided with the Item
Synchronization for Suppliers solution. It maintains the complete list
of the supplier's items that exist in the UCCnet repository by using each
item's tracking ID, or GTIN, as the primary key. This table
permits a UCCnet_processWorklist collaboration object to process incoming
INITIAL_ITEM_LOAD_REQUEST commands without the need to communicate with the
back-end ERP system. See the section INITIAL_ITEM_LOAD_REQUEST subdiagram for more information on this subdiagram.
The UCCnet_ItemSync and UCCnet_processWorklist collaboration objects both
interact with this table. A UCCnet_ItemSync collaboration object
updates the table each time it processes an ItemBasic business object.
The collaboration object performs this processing only if all of the fields
for which UCCnet requires data are complete (see the section Checking that item data exists for fields required by UCCnet for more information). The type of processing the
collaboration object performs depends on the verb attached to the ItemBasic
business object, as follows:
- If the ItemBasic business object has a Create verb, the
UCCnet_ItemSync collaboration object checks if the item exists in the
PROCESSED_GTIN table and processes it, as follows:
- If the item does not already exist in the PROCESSED_GTIN table, the
collaboration object adds an entry for it to the table, and sets the value for
the withdrawn field for this entry to N.
- If the item already exists in the table, the collaboration object changes
its verb to Update.
- If the ItemBasic business object has an Update verb, the
UCCnet_ItemSync collaboration object checks if the item exists in the
PROCESSED_GTIN table and processes it, as follows:
- If the item exists in the table and the value for its withdrawn
field is set to N, the collaboration object continues processing
it.
- If the item exists in the table and the value for its
withdrawn field is set to Y, the collaboration object
does the following:
- Changes the value of the entry's withdrawn field to
N.
- Changes the value of the entry's delete field to
U.
- Changes the business object verb to UNWITHDRAWN.
- Continues processing it.
- If the item does not exist in the table, the collaboration object changes
the business object's verb to Create and adds it to the
PROCESSED_GTIN table, setting the entry's withdrawn field to
N.
- If the ItemBasic business object has a Delist verb, the
UCCnet_ItemSync collaboration object removes the item from the PROCESSED_GTIN
table.
- If the ItemBasic business object has a Withdraw verb, the
UCCnet_ItemSync collaboration object locates the item in the PROCESSED_GTIN
table and sets the value for the entry's withdrawn field to
Y. This action prevents the publication of the item in
response to an incoming INITIAL_ITEM_LOAD_REQUEST.
The UCCnet_processWorklist collaboration object reads this table during
processing, as follows:
- Its NEW_ITEM_PUBLICATION_REQUEST subdiagram verifies that specific items
are in the table.
- Its INITIAL_ITEM_LOAD_REQUEST subdiagram generates publication messages
for all items in the table with a withdrawn value of N.
The UCCnet_ItemSync collaboration object connects to the database through
its GtinDB_USER, GtinDB_PASSWORD, JDBC_DRIVER, and JDBC_URL configuration
properties; the UCCnet_processWorklist collaboration object, through its
DB_USER, DB_PASSWORD, JDBC_DRIVER, and JDBC_URL configuration
properties. See Collaboration for UCCnet Item
Synchronization for detailed information on these properties.
Connection information for the PROCESSED_GTIN table is configured as part
of the UCCnet_ItemSync collaboration object setup. After the
relationships have been deployed, the table itself is created by running the
supplied InitializeRelationshipTables.sql file for the database type
(i.e., DB2(R), Oracle, or Microsoft(R) SQL
Server). See the Installation guide for installation
instructions.
The audit_log table is provided with the Item Synchronization for Suppliers
solution. It is used to track the events associated with UCCnet
activities to support complete end-to-end auditing. This audit support
provides irrefutable documentation that transmissions have occurred between
trading partners. It also provides a profile of which trading partners
are participating in the trading community and with which products that
participation is associated.
The audit service is composed of four components:
UCCnet_ItemSync and UCCnet_processWorklist collaboration objects impact the
audit_log table. Any time an item is added to, updated or delisted
within, or withdrawn from the ERP, and an ItemBasic business object is
subsequently passed to a UCCnet_ItemSync collaboration object, the
collaboration object records an entry in the audit_log table detailing the
event. The following subdiagrams of the UCCnet_processWorklist
collaboration object also record entries in the audit_log table during
processing:
- AUTHORIZATION_RESPONSES
- CATALOGUE_ITEM_CONFIRMATION
- INITIAL_ITEM_LOAD_REQUEST
- ITEM_ADD_CHANGE
- NEW_ITEM_PUBLICATION_REQUEST
- RCIR_RESPONSE
The following sections have more information on how these subdiagrams
operate:
Each audit entry is associated with the value listed for the collaboration
object's SUPPLIER_NAME attribute.
Connection from the UCCnet_ItemSync and UCCnet_processWorklist
collaboration objects to the audit_log table is provided by the IBM JDBC
Driver for DB2, Oracle, or Microsoft SQL Server. Table creation is
performed via running the supplied audit_log.sql file for the database
type (i.e., DB2, Oracle, or Microsoft SQL Server). See
the Installation guide for installation
instructions.
The trading_partner table, or GLN table, is a relational table provided
with the Item Synchronization for Suppliers solution. It maintains the
complete list of trading partners by using the Global Location Number (GLN) of
each as the key.
The NEW_ITEM_PUBLICATION_REQUEST subdiagram of a
UCCnet_processWorklist collaboration object checks that a new item or updated
item information to be published is supplied by a trading partner from this
table. It also verifies that the demand-side trading partners to whom
notification will be sent are in the table. The
INITIAL_ITEM_LOAD_REQUEST subdiagram of a UCCnet_processWorklist collaboration
object checks the trading_partner table to verify that the demand-side trading
partner requesting the INITIAL_ITEM_LOAD_REQUEST exists. The
ITEM_ADD_CHANGE subdiagram of a UCCnet_processWorklist collaboration object
utilizes maps that read from the trading_partner table.
Connection information for the trading_partner table is configured
as part of the UCCnet_processWorklist collaboration object.
The table itself is created when the TPTable relationship is deployed (and
the schema is created). The InitializeRelationshipTables scripts
(InitializeRelationshipTables.sql and
InitializeRelationshipTablesForXSD.sql) make alterations to the table
then make alteration to the table. These changed include the addition
of the following columns to the table:
The following columns are added to the table via running the supplied
InitializeRelationshipTables.sql file for the database type
(i.e., DB2, Oracle, or Microsoft SQL Server):
- gln_code
- trading_partner_name
- trading_partner_contact
- trading_partner_group
- trading_partner_type
- initial_load_flag
After the columns are created, you must manually populate it with the
correct information. See the Installation guide for
installation instructions.
All messages initiated from UCCnet are in UCCnet XML format. Since
the UCCnet XML format's top-level tag (<envelope>) is the same for all
messages, a component is needed to distinguish among the various notification
and response XML messages and return different business objects for
them. An object based on the UCCnet_processWorklist collaboration
template performs this task.
A UCCnet_processWorklist collaboration object is instantiated when the AS2
channel connector forwards a UCCnetGBO_envelope business object to it.
See Receiving data for a collaboration object from UCCnet for details of how this business object is created.
The UCCnet_processWorklist collaboration object parses the
UCCnetGBO_envelope business object, creating a separate UCCnetGBO_envelope
business object for each notification or response. The collaboration
object routes each business object representing a single notification to the
appropriate subdiagram. Each subdiagram handles a particular set of
notification or response messages, as follows:
- AUTHORIZATION_RESPONSES subdiagram -- Handles notifications for the
topics AUTHORIZE, DE_AUTHORIZATION, PEND_PUBLICATION, PRE_AUTHORIZATION, and
REJECT_PUBLICATION. See the section AUTHORIZATION_RESPONSES subdiagram for more information on this subdiagram.
- CATALOGUE_ITEM_CONFIRMATION -- Handles the process of the
CATALOGUE_ITEM_CONFIRMATION responses, received by the UCCnet_processWorklist
collaboration object. See CATALOGUE_ITEM_CONFIRMATION subdiagram for more information.
- CATEGORY_ADD_CHANGE subdiagram -- Handles notifications for the
CATEGORY_ADD and CATEGORY_CHANGE topics. See the section CATEGORY_ADD_CHANGE subdiagram for more information on this subdiagram.
- CIN_RESPONSE subdiagram -- Handles incoming messages that are
recognized as CIN_RESPONSE messages. See the section CIN_RESPONSE subdiagram for more information on this subdiagram.
- DEAD_LETTER_PUB_RECEIPT subdiagram -- Handles notifications
associated with the single notification topic DEAD_LETTER_PUB_RECEIPT.
See the section DEAD_LETTER_PUB_RECEIPT subdiagram for more information on this subdiagram.
- INITIAL_ITEM_LOAD_REQUEST subdiagram -- Handles notifications
associated with the single notification topic
INITIAL_ITEM_LOAD_REQUEST. See the section INITIAL_ITEM_LOAD_REQUEST subdiagram for more information on this
subdiagram.
- ITEM_ADD_CHANGE subdiagram -- Handles notifications for the ITEM_ADD
and ITEM_CHANGE topics. See the section ITEM_ADD_CHANGE subdiagram for more information on this subdiagram.
- NEW_ITEM_PUBLICATION_REQUEST subdiagram -- Handles notifications
associated with the single notification topic
NEW_ITEM_PUBLICATION_REQUEST. See the section NEW_ITEM_PUBLICATION_REQUEST subdiagram for more information on this
subdiagram.
- PUBLICATION_COMMAND_RESPONSE subdiagram -- Handles incoming messages
that are recognized as CI_RESPONSE or CIP_RESPONSE messages. See the
section PUBLICATION_COMMAND_RESPONSE subdiagram for more information on this subdiagram
- RCIR_RESPONSE -- Handles notifications for the ADD and CHANGE
topics. See the section RCIR_RESPONSE subdiagam for more information.
- RCIR_QUERY_RESPOINSE -- Handles incoming messages that are recognized
as RCIR_QUERY_RESPONSE messages. See the section RCIR_QUERY_RESPONSE subdiagram for more information.
- SIMPLE_RESPONSE subdiagram -- Handles immediate responses to commands
such as MDNs from UCCnet. See the section SIMPLE_RESPONSE subdiagram for more information on this subdiagram.
- UNKNOWN_MESSAGES subdiagram -- Handles incoming messages not
recognized as supported. See the section UNKNOWN_MESSAGES subdiagram for more information on this subdiagram.
- UNKNOWN_RESPONSE subdiagram -- Handles incoming messages that are
recognized as notification messages, but are not supported. See the
section UNKNOWN_RESPONSE subdiagram for more information on this subdiagram.
This subdiagram handles notifications for the following topics:
AUTHORIZE, DE_AUTHORIZATION, PEND_PUBLICATION, PRE_AUTHORIZATION, and
REJECT_PUBLICATION. UCCnet generates these notifications as a result of
authorization actions taken by demand-side trading partners, which are
forwarded to UCCnet. Typically they are issued in response to an
ItemPublicationAdd issued by the supply-side trading partner, but they can be
issued at anytime. The subdiagram logic does the following:
- Instantiates a collaboration object based on the Notify_by_eMail
collaboration template, which sends an email to selected recipients.
The email message, subject, and recipients are configured in this
collaboration object's EMAIL_MESSAGE, EMAIL_SUBJECT, and
EMAIL_NOTIFICATION_RCPTS configuration properties, respectively. See
the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
- Logs the event in the audit_log table. See Using the audit_log table for more information on the audit_log table.
This subdiagram handles notifications for the CATEGORY_ADD and
CATEGORY_CHANGE topics. These notifications are sent by UCCnet when a
request is made by the supply-side trading partner to add or change a category
to better classify or organize the items in its available inventory.
The subdiagram logic sends an email containing the category maintenance
information to selected recipients by instantiating a collaboration object
based on the Notify_by_eMail collaboration template.. The email
message, subject, and recipients are configured in this collaboration
object's EMAIL_MESSAGE, EMAIL_SUBJECT, and EMAIL_NOTIFICATION_RCPTS
configuration properties, respectively. See the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information. There is no follow-on
flow.
This subdiagram handles the process of the CATALOGUE_ITEM_CONFIRMATION
responses, received by the UCCnet_processWorklist collaboration object.
UCCnet generates these responses as a result of the authorization actions
taken by demand-side trading partners. The responses can have one of
the following states:
- SYNCHRONISED
- ACCEPTED
- REVIEW
- REJECTED
The responses are normally generated in answer to a request generated by
the supply-side trading partner as part of the
CatalogueItemNotification_Change and CatalogueItemNotification_Add
workflows. However, the responses can be issued at any time.
This subdiagram carries out the following logic:
- It instantiates a collaboration object based on the Notify_by_eMail
collaboration template. This collaboration object sends an email to a
set of defined recipients. The message, subject, and recipient list are
defined by the collaboration object's EMAIL_MESSAGE, EMAIL_SUBJECT, and
EMAIL_NOTIFICATION_RCPTS configuration properties, respectively. See
the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
- It logs the event in the audit_log table. See the section Using the audit_log table for more information.
This subdiagram handles incoming CIN_Response messages. The
subdiagram logic instantiates a collaboration object based on the
Notify_by_eMail collaboration template, which sends an email to selected
recipients. The email message, subject, and recipients are configured
in this collaboration object's EMAIL_MESSAGE, EMAIL_SUBJECT, and
EMAIL_NOTIFICATION_RCPTS configuration properties, respectively. See
the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
This subdiagram handles notifications for the DEAD_LETTER_PUB_RECEIPT
topic. These notifications result from a supplier request for which a
target demand-side trading partner has not subscribed. The subdiagram
logic instantiates a collaboration object based on the Notify_by_eMail
collaboration template, which sends an email to selected recipients.
The email message, subject, and recipients are configured in this
collaboration object's EMAIL_MESSAGE, EMAIL_SUBJECT, and
EMAIL_NOTIFICATION_RCPTS configuration properties, respectively. See
the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
This subdiagram handles notifications associated with the single
notification topic INITIAL_ITEM_LOAD_REQUEST. This notification is
generated as a result of a demand-side trading partner requesting through
UCCnet to initiate synchronizing all the items currently traded with a given
supply-side trading partner. The demand-side partner's request
produces a notification in the worklist of the supply-side trading
partner.
The logic in this subdiagram does the following:
- Writes a record to the audit_log table indicating receipt of the
INITIAL_ITEM_LOAD_REQUEST. See the section Using the audit_log table for more information on the audit_log table.
- Checks the trading_partner table to verify that the GLN requesting the
INITIAL_ITEM_LOAD_REQUEST exists. See the section Using the trading_partner table for more information on the trading_partner table.
- Sends the business object to UCCnet over the
INITIAL_ITEM_LOAD_REQUEST port via the AS2 channel
connector.
The follow-up workflow is that of an ItemPublicationAdd subflow 1 targeted
to the trading partner who initiated the flow, as detailed in the section ItemPublicationAdd subflow 1. The PROCESSED_GTIN table provides the list of GTINs
for the ItemPublicationAdd, and the incoming message provides the trading
partner's GLN. There are no external business process steps for
this flow.
This subdiagram handles notifications for the ITEM_ADD and ITEM_CHANGE
topics. These notifications are sent by UCCnet to indicate completion
of a particular item synchronization request, such as one initiated by an
ItemAdd or ItemChange workflow. The subdiagram logic does the
following:
- Receives the UCCnetGBO_envelope business object.
- Configures it so that the correct maps will be used by the AS2 channel
connector.
- Sends the UCCnetGBO_envelope over the ITEM_ADD_CHANGE port to the AS2
channel connector where it is mapped to an ItemPublicationAdd or
ItemPublicationChange request.
- Logs the notification in the audit_log table. See the section Using the audit_log table for more information on the audit_log table.
The follow-up workflow is that of the first subflow of either the
ItemPublicationAdd or ItemPublicationChange workflow, as detailed in the
sections ItemPublicationAdd subflow 1 and ItemPublicationChange subflow 1.
This subdiagram handles notifications associated with the single
notification topic NEW_ITEM_PUBLICATION_REQUEST. This notification is
generated as a result of the following:
- A new item being added to the source ERP.
- Item data being updated in the source ERP.
- A demand-side trading partner requesting through UCCnet that a supply-side
trading partner publish a specific item (GTIN) or items to it so it can
synchronize them. The demand-side partner's request produces a
notification in the worklist of the supply-side trading partner. This
notification has the type="NEW_ITEM_PUBLICATION_REQUEST".
The logic in this subdiagram does the following:
- Verifies that the GTIN value associated with the item is in the
PROCESSED_GTIN table and that the item is not withdrawn. See the
section Using the PROCESSED_GTIN table for more information on the PROCESSED_GTIN table.
- Checks that the new item or new item information to be published is
supplied by a trading partner listed in the trading_partner table and verifies
that the demand-side trading partners to whom notification will be sent are
also in this table. See the section Using the trading_partner table for more information on the trading_partner table.
- Configures the business object so that the correct maps will be used by
the AS2 channel connector.
- Logs the notification in the audit_log table. See the section Using the audit_log table for more information on the audit_log table.
The follow-up workflow is that of the second subflow of either the
ItemPublicationAdd or ItemPublicationChange workflow, as detailed in the
sections ItemPublicationAdd subflow 2 and ItemPublicationChange subflow 2.
This subdiagram handles incoming CI response and CIP response messages as
follows:
- It writes a record to the audit_log table indicating receipt of the CI or
CIP response message.See the section Using the audit_log table for more information on the audit_log table. .
- If the received message is a CIP_RESPONSE, then it sends the
UCCnetGBO_envelope through the CIP_RESPONSE port to the a Notify_by_eMail
collaboration object to notify the supplier, and then exits.
- Otherwise, it creates an empty ItemBasic business object and sends it to
the DestinationAppRetrieve port with a retrieve verb. This actions
retrieves the ItemBasic business that initiated the corresponding RCIR command
originally sent to UCCnet.
- If the retrieved ItemBasic business object indicates a CHANGE, the
subdiagram sends a UCCnetGBO_envelope business object through CI_RESPONSE port
to a Notify_by_eMail collaboration object to notify the supplier, and then
exits.
- If the retrieved ItemBasic BO indicates an ADD, the subdiagram sends the
business object out the PUBLICATION_CMD_RESPONSE port to an instance of the
CIN_CIP_Dispatcher collaboration object to initiate sending of CIPs.
This subdiagram handles notifications for the ADD and CHANGE topics.
These notifications are sent by UCCnet when a request in made by the
supply-side trading partner to add or change an item.
The subdiagram logic first records the occurrence of the RCIR_RESPONSE
message in the audit_log. Then, it builds a skeleton ItemBasic business
object, defining only the UPCEANCODE and ITEM_DOMAIN attributes. It
next sends this ItemBasic business object out through the
DestinationAppRetrieve port so that the user can respond with a completed
ItemBasic business object. In a production environment, an additional
process is required to retrieve the fully defined ItemBasic business object
using the UPCEANCODE and ITEM_DOMAIN fields, and to return it to the
DestinationAppRetrieve port.
Once the fully defined ItemBasic business object has been returned:
- For CIN operation
- The RCIR_RESPONSE subdiagram sends it out through the RCIR_RESPONSE port
to the CIN_CIP_Dispatcher collaboration object. This action triggers
the CIN_CIP_Dispatcher collaboration object to generate
CATALOGUE_ITEM_NOTIFICATION messages and send one to each subscribed
demand-side trading partner.
- Note:
- CATALOGUE_ITEM_NOTIFICATION is a general term. The workflow
explanations refer to either a CatalogueItemNotificaton_ADD message, or a
CatalogueItemNotification_CHANGE as specific instances of a
CATALOGUE_ITEM_NOTIFICATON message.
- For CIP operation
- The RCIR_RESPONSE subdiagram sends it out through the RCIR_RESPONSE port
to an AS2 channel connector, which maps it to a Catalogue Item message and
sends it to UCCnet.
The follow-up workflow is the CatalogueItemNotification_Add or
CatalogueItemNotification_Change workflow, as detailed in the sections CatalogueItemNotification_Add and CatalogueItemPublication_Add workflows and CatalogueItemNotification_Change and CatalogueItemPublication_Change workflow. Ensure that the schema delist and
withdrawal workflows do not use this subdiagram.
This subdiagram handles incoming RCIR Query response messages. The
subdiagram logic instantiates a collaboration object based on the
Notify_by_eMail collaboration template, which sends an email to selected
recipients with the contents of the received message. The email
message, subject, and recipients are configured in this collaboration
object's EMAIL_MESSAGE, EMAIL_SUBJECT, and EMAIL_NOTIFICATION_RCPTS
configuration properties, respectively. See the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
This subdiagram handles immediate responses to commands such as MDNs from
UCCnet. The subdiagram logic instantiates a collaboration object based
on the Notify_by_eMail collaboration template, which sends an email to
selected recipients. The email message, subject, and recipients are
configured in this collaboration object's EMAIL_MESSAGE, EMAIL_SUBJECT,
and EMAIL_NOTIFICATION_RCPTS configuration properties, respectively.
See the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
This subdiagram handles incoming messages not recognized as
supported. The subdiagram logic instantiates a collaboration object
based on the Notify_by_eMail collaboration template called, which sends an
email to selected recipients. The email message, subject, and
recipients are configured in this collaboration object's EMAIL_MESSAGE,
EMAIL_SUBJECT, and EMAIL_NOTIFICATION_RCPTS configuration properties,
respectively. See the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
This subdiagram handles incoming messages that are recognized as
notification messages, but are not supported. The subdiagram logic
instantiates a collaboration object based on the Notify_by_eMail collaboration
template, which sends an email to selected recipients. The email
message, subject, and recipients are configured in this collaboration
object's EMAIL_MESSAGE, EMAIL_SUBJECT, and EMAIL_NOTIFICATION_RCPTS
configuration properties, respectively. See the section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information.
UCCnet_ItemSync and UCCnet_processWorklist collaboration objects can be
configured to send email to alert when processing errors occur. A
UCCnet_processWorklist collaboration object can also instantiate collaboration
objects based on the Notify_by_eMail collaboration template to respond by
email to configured recipients when specific processing circumstances
occur.
For more information on these topics, see the following sections:
UCCnet_ItemSync and UCCnet_processWorklist collaboration objects can be
configured to send email to alert recipients when processing errors
occur.
- UCCnet_ItemSync collaboration object
- This collaboration object uses two configuration properties to control
whether email is sent and to identify the mail recipients.
- SEND_EMAIL -- This property controls whether email is sent to the
email address specified in the SEND_EMAIL_TO configuration property.
Set the property value to all to send email or to none
to not send email. If the value is left empty, no email is sent even if
recipients exist in the SEND_EMAIL_TO property.
- SEND_EMAIL_TO -- This property defines the email addresses to which
error messages are sent. Multiple addresses can be provided in a
comma-delimited list. This property must be configured by the
user.
- UCCnet_processWorklist collaboration object
- This collaboration object uses one configuration property to control
whether email is sent and to identify the mail recipients. The
SEND_EMAIL_TO property defines the email addresses to which error messages are
sent. Multiple addresses can be provided in a comma-delimited
list. If a value exists for this property, the collaboration object
sends email. If the property is left blank, the object does not send
email. This property must be configured by the user.
A UCCnet_processWorklist collaboration object contains several subdiagrams
that respond to specific types of workflow processing. The following
subdiagrams include functionality that sends an email to a set of configured
addresses by instantiating a collaboration object based on the Notify_by_eMail
collaboration template:
- CATEGORY_ADD_CHANGE subdiagram
- AUTHORIZATION_RESPONSES subdiagram
- DEAD_LETTER_PUB_RECEIPT subdiagram
- CATALOGUE_ITEM_CONFIRMATION subdiagram
- SIMPLE_RESPONSE subdiagram
- UNKNOWN_MESSAGES subdiagram
- UNKNOWN_RESPONSE subdiagram
Each of these subdiagrams instantiates an object based on the
Notify_by_eMail collaboration template, which can be configured to contain the
email message, subject, and recipients specific to its processing situation
through its EMAIL_MESSAGE, EMAIL_SUBJECT, and EMAIL_NOTIFICATION_RCPTS
configuration properties, respectively. These properties can also
contain the names of files, which permits messages, subjects, and recipients
to be shared among multiple collaboration objects. Also, more than one
recipient can be specified to receive email through use of a comma-delimited
list. Plus, email message and subject text can be constants that
contain variables. The Notify_by_eMail collaboration object substitutes
data from the business object into these variables dynamically. See the
following sections for more information on these features:
The value of the AUTO_RESPOND property of the UCCnet_processWorklist
collaboration object determines whether email is sent. The value of
this collaboration object's DTD_URL property sets the DTD line in the XML
in any outgoing XML message.
A Notify_by_eMail collaboration object allows the contents of its
properties that specify email message text, subject text, and recipients to
contain the names of files. These files contain the actual email
message text, subject text, and addresses, and can be easily modified without
modifying the using collaboration objects. This feature permits
messages, subjects, and recipients to be shared among multiple collaboration
objects. A solution's messages, subjects, and recipients can all
be contained in one easily modifiable directory.
A Notify_by_eMail collaboration object uses the following configuration
properties to identify the email message text, subject text, and
recipients:
- EMAIL_MESSAGE
- Identifies the message text.
- EMAIL_SUBJECT
- Identifies the subject text.
- EMAIL_NOTIFICATION_RCPTS
- Identifies the recipient or list of recipients.
The collaboration object distinguishes whether the content of a property is
an actual value or filename based on whether the value is prefixed by the
character @. If the value of the property is prefixed with
the character @, the Notify_by_eMail collaboration object
interprets the rest of the value as a filename. The collaboration
object reads the value of the file into a String variable in preparation for
further processing. Files must be identified by their fully qualified
names.
For instance, if the filename containing the email recipients is
c:\Email_Files\CategoryManagerRole.txt, set the value
of the EMAIL_NOTIFICATION_RCPTS property, as follows:
@c:\Email_Files\CategoryManagerRole.txt
If the value of a property does not start with the character @,
the Notify_by_eMail collaboration object obtains the email value directly from
the attribute.
A Notify_by_eMail collaboration object allows all email messages to be
routed to an administrator or to a specific role in an organization (like a
Category Manager), without the need to maintain the email recipient's
fully qualified email address in every collaboration object that might send
email. By placing the email address in an external file, if the address
changes, the file can be modified without having to reconfigure the using
collaboration objects. More than one recipient can be specified to
receive the email through use of a comma-delimited list. The
comma-delimited list can be specified in the business object attribute or in
the external file pointed to by the attribute.
Email message and subject text can be constants that contain
variables. A collaboration object based on the Notify_by_eMail template
substitutes data from the business object into these variables
dynamically. Variables to be substituted must be enclosed in the prefix
characters ${ and the suffix character }. As a
result, the substitution variables in the email message and subject text must
appear as:
${variable_name}
- Note:
- These characters might have to be changed to meet National Language
requirements.
The supported values for variable_name, along with the values
that the collaboration object actually inserts in the text, are as
follows:
- getRoot
- Substitutes the entire triggering business object.
- getDate
- Substitutes the current date and time.
- getName
- Substitutes the name of the triggering business object.
- getVerb
- Substitutes the verb of the triggering business object.
- Any attribute name
- Substitutes the value of the named attribute from the triggering business
object.
If the value for variable_name does not match one of the
specific values above, the collaboration object interprets it as the name of a
business object attribute. For instance, in the following sample
message:
UCCnet_processWorklist_AUTHORIZATION_RESPONSES.mail: \
Date: ${getDate}
BusinessObject: ${getName}.${getVerb}
Topic:
${ROOT.body[0].response.acknowledge.acknowledgement. \
subdocumentValid[0].subdocumentValid[0]resultList[0]. \
notification.topic}
GLN:
${ROOT.body[0].response.acknowledge.acknowledgement. \
subdocumentValid[0].subdocumentValid[0].resultList[0]. \
notification.notificationDetail.transactionInformation. \
entityIdentification.globalLocationNumber.gln}
GTIN:
${TLO.body.body_Wrapper1[0].response.acknowledge. \
acknowledgement.subdocumentValid[0].subdocumentValid[0]. \
resultList.resultList_Wrapper1[0].notification. \
notificationDetail.authorizationNotification.publication. \
item.itemInformation.globalTradeItemNumber.gtin}
${getRoot}
the following variables are filled in automatically during the generation
of the message, as follows:
- ${getDate}, with the current date and time.
- ${getName}, with the name of the triggering business
object.
- ${getVerb}, with the verb of the triggering business
object.
- All variables beginning with ${ROOT.body[0]. .
.}, with the values for those attributes.
- ${getRoot} with the entire triggering business object.
If UCCnet_ItemSync, UCCnet_requestWorklist, UCCnet_processWorklist, and
Notify_by_eMail collaboration objects encounter error situations during any
stage of processing, they do the following:
- Log the error in the configured log destination.
- Return the object to the calling collaboration object through the
From port.
- Note:
- For error logging to occur, tracing must be enabled. Also, use
separate files for tracing and logging. Use logging files to maintain
persistent records of processed data. Use tracing files to diagnose
problems and to show the flow of an item through the Item Synchronization for
Suppliers solution. The Log Viewer tool has log and trace file filters
that enable users to view the log or trace records for a particular business
object or collaboration object.
All collaboration objects based on collaboration templates included in the
Item Synchronization for Suppliers solution provide tracing capabilities to
record logical flows and data processed. Users can enable tracing for a
particular collaboration object by selecting the collaboration object in the
System Manager, displaying its properties, and, on the Collaboration
General Properties tab, selecting a trace level greater than
0 from the System trace level field.
Enable tracing for one or more collaboration objects when a reproducible
problem occurs. If a problem occurs only once during processing, leave
the tracing function enabled continually so that the first occurrence of the
failure is captured. However, leaving the tracing function enabled
continually can degrade performance. Clear the trace file periodically
to simplify viewing and filtering it.
- Note:
- Use separate files for tracing and logging. Use tracing files to
diagnose problems and to show the flow of an item through the Item
Synchronization for Suppliers solution. Use logging files to maintain
persistent records of processed data. The Log Viewer tool has trace and
log file filters that enable users to view the trace or log records for a
particular business object or collaboration object.
