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:
For Schema 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.
- Polling UCCnet for worklists 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 will determine the connector that you use to
communicate with it. If you exchange messages with UCCnet using an
AS2/EDIINT interface protocol, you can use either a TPIConnector or an
ISoftConnector. Use the TPI connector if you communicate with UCCnet
through Trading Partner Interchange servers. Use the ISoftConnector if
you are communicating with UCCnet through an iSoft Peer-to-Peer Agent.
If you exchange messages through the UCCnet Command Line Utitily (CLU) or are
testing your installation, you can use either a JTextTPIConnector, or a
JTextISoftConnector.
Since the actual connector you use is dependent on your set up, the term
"AS2 channel connector" is used throughout this documentation as a
general term for any of the TPIConnector, ISoftConnector, JTextTPIConnector,
and JTextISoftConnector.
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 flaws and data
processed. See the section Tracing for detailed information.
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 -
ItemPublicationAdd detailed in the section ItemPublicationAdd workflow: making a new item available to trading partners and processing their responses -- accomplishes sending these notifications.
Notes:
- The mappings used in processing ItemAdd messages use value translation
tables. The IBM(R) WebSphere(R) InterChange Server implements
these tables as cross-references.
- If you are using schema support, refer to the documentation found in ItemAdd workflow: adding a new item to UCCnet (schema 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. In this example, we use the
SAPConnector. The SAPConnector converts the input from the ERP into a
SAP application specific business object.
- The SAPConnector passes the SAP application specific business object to a
UCCnet_ItemSync collaboration object, first transforming it into a generic
ItemBasic business object with a Create verb by passing it through
the Sa4CwItemBasic input map.
- The UCCnet_ItemSync collaboration object accepts the object on its
From port and checks that required fields contain 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. If all required fields
are not complete, the collaboration object aborts processing and sends an
email to a configured address, as detailed in the section Alerting email recipients of processing errors. For this example, assume 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 identify the ItemAdd transaction processed. See the section Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration object delivers the ItemBasic
business object to the AS2 channel connector over its To
port. In the connector controller, it is converted into an application
specific business object, either a UCCnetDTD_envelope business object (if
iSoft connectivity is used) or a UCCnetTPIDTD_envelope business object (if TPI
connectivity is used). The ItemBasic business object is converted by
passing through the RouterMap_CwItemBasic_to_UCCnetDTD_envelope router map and
CwItemBasic_to_UCCnetDTD_envelope_documentCommand_item translation map (if
iSoft connectivity is used) or the
RouterMap_CwItemBasic_to_UCCnetTPIDTD_envelope router map and the
CwItemBasic_to_UCCnetTPIDTD_envelope_documentCommand_item translation map (if
TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the ItemAdd XML
message in UCCnet format.
- The AS2 channel connector passes this message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
ItemAdd message to UCCnet.
- UCCnet generates and returns to the AS2 channel server a Message
Disposition Notification (MDN) to indicate successful receipt of the ItemAdd
message.
- The AS2 channel server delivers the MDN to the AS2 channel
connector.
- The AS2 channel connector sends the MDN to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is
used).
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the
business object on its From port, identifies it as an MDN, and
dispatches it to its SIMPLE_RESPONSE subdiagram. See the section SIMPLE_RESPONSE subdiagram for more information on this subdiagram.
- The SIMPLE_RESPONSE subdiagram sends email to the recipients configured in
the UCCnet_processWorklist_SIMPLE_RESPONSEObject collaboration object (an
instance of the Notify_by_eMail collaboration template). See the
section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information on how to configure properties
controlling email.
- UCCnet creates a worklist containing the notification response for a
successful ItemAdd.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependent on platform) that is created during
installation of the solution to the event directory of the
JTextRWLConnector:
- On Windows(R) systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX(R) systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector retrieves the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into a UCCnetDTD_envelope
business object (if iSoft connectivity is used) or a UCCnetTPIDTD_envelope
business object (if TPI connectivity is used). This business object
contains the entire UCCnet message, including each individual data instance
and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope map (if iSoft
connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope map
(if TPI connectivity is used).
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the
connector controller, it is converted to a UCCnetDTD_envelope business object
(if iSoft connectivity is used) or a UCCnetTPIDTD_envelope business object (if
TPI connectivity is used). The UCCnetGBO_envelope business object is
converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_to_UCCnetDTD_envelope router and translation maps (if iSoft
connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope router and translation maps (if
TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the notification response for a
successful ItemAdd to the AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM
WebSphere Business Integration Data Handler for XML, which converts it into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
This business object contains the entire UCCnet notification, including each
individual data instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the
business object on its From port, identifies it as an ItemAdd
notification, and dispatches it to its ITEM_ADD_CHANGE 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. This on-going workflow,
referred to as the ItemPublicationAdd workflow, is continued in the section ItemPublicationAdd workflow: making a new item available to trading partners and processing their responses.
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: adding a new item to UCCnet (DTD 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. As a result, the ItemPublicationAdd
workflow is described as two subflows:
The following description shows how the ItemPublicationAdd workflow makes a
new item available to a supplier's demand-side trading partners.
At this point in processing, the ItemAdd workflow has completed and a
UCCnetGBO_envelope business object has arrived in the ITEM_ADD_CHANGE
subdiagram of the UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object's ITEM_ADD_CHANGE
configures the business object so that the router map will select the correct
transformation map. See the section ITEM_ADD_CHANGE subdiagram for more information on this subdiagram.
- The AS2 channel connector maps the UCCnetGBO_envelope business object into
either a UCCnetDTD_envelope business object (if iSoft connectivity is used) or
a UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
The UCCnetGBO_envelope business object is converted by passing through either
the RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_notification_to_UCCnetDTD_envelope_publishCommand router
and input maps (if iSoft connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_notification_to_UCCnetTPIDTD_envelope_publishCommand router
and input maps (if TPI connectivity is used). The business object
contains the corresponding ItemPublicationAdd request. This message
includes a request for UCCnet to publish the item to the trading partners
listed in the message
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the
ItemPublicationAdd XML message in UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
ItemPublicationAdd message to UCCnet.
- UCCnet generates and sends to the AS2 channel server an MDN indicating
successful receipt of the ItemPublicationAdd message.
- The AS2 channel server delivers the MDN to the AS2 channel
connector.
- The AS2 channel connector sends the MDN to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into either a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is
used).
- The business object is converted to a UCCnetGBO_envelope business object
by passing through an either the UCCnetDTD_envelope_to_UCCnetGBO_envelope
input map (if iSoft connectivity is used) or the
UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope input map (if TPI connectivity is
used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the
business object on its From port, identifies it as an MDN, and
dispatches it to its SIMPLE_RESPONSE subdiagram. See the section SIMPLE_RESPONSE subdiagram for more information on this subdiagram.
- The SIMPLE_RESPONSE subdiagram sends email to the recipients configured in
the UCCnet_processWorklist_SIMPLE_RESPONSEObject collaboration object (an
instance of the Notify_by_eMail collaboration template). See the
section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information on how to configure properties
controlling email.
- UCCnet performs a compliance check on the data and, if all data exists in
the appropriate formats, creates a worklist containing a PUB_RELEASE_NEW_ITEM
notification to indicate a successful ItemPublicationAdd.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependent on platform) that is created during
installation of the solution to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector retrieves the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into either a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
This business object contains the entire UCCnet message, including each
individual data instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through either the UCCnetDTD_envelope_to_UCCnetGBO_envelope input
map (if iSoft connectivity is used) or the
UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope input map (if TPI connectivity is
used).
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the
connector controller, it is converted to either a UCCnetDTD_envelope business
object (if iSoft connectivity is used) or a UCCnetTPIDTD_envelope business
object (if TPI connectivity is used). The UCCnetGBO_envelope business
object is converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_to_UCCnetDTD_envelope router and translation maps (if iSoft
connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope router and translation maps (if
TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the PUB_RELEASE_NEW_ITEM
notification indicating a successful ItemPublicationAdd to the AS2 channel
server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM
WebSphere Business Integration Data Handler for XML, which converts it into
either a UCCnetDTD_envelope business object (if iSoft connectivity is used) or
a UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
This business object contains the entire UCCnet notification, including each
individual data instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the object
on its From port, identifies it as a PUB_RELEASE_NEW_ITEM, and
dispatches it to its NEW_ITEM_PUBLICATION_REQUEST subdiagram. See the
section NEW_ITEM_PUBLICATION_REQUEST subdiagram for more information on this subdiagram.
As a result of this subflow of the ItemPublicationAdd workflow, a new item
is made available to a supplier's demand-side trading partners.
The on-going subflow that alerts them of the item's existence and
processes their responses, referred to as the ItemPublicationAdd subflow 2, is
continued in the section ItemPublicationAdd subflow 2: processing trading partners' responses to a new item.
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 description describes how the ItemPublicationAdd workflow
alerts demand-side trading partners that a new item is available and processes
their responses:
- The UCCnet_processWorkflow collaboration object's
NEW_ITEM_PUBLICATION_REQUEST subdiagram logic 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 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 connector.
- Sends the ItemPublicationAdd for the GTIN to the demand-side trading
partners identified in the business object. The message is sent over
the NEW_ITEM_PUBLICATION_REQUEST port to 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 AS2 channel connector maps the business object into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
The business object is converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_notification_to_UCCnetDTD_envelope_publishCommand maps (if
iSoft connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_notification_to_UCCnetTPIDTD_envelope_publishCommand (if
TPI connectivity is used).
- The business object is converted to XML, delivered to the AS2 channel
server, and then to UCCnet.
- 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 user's legacy environment and the demand-side user is ready
to begin trading.
- PEND_PUBLICATION -- The demand-side user 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 user has no interest in the
product.
- PRE_AUTHORIZATION -- The demand-side user wants to begin the process
of integrating the product into its legacy environment. This response
might indicate that the supplier contact the demand-side user to begin the
process of deciding on order quantities, pricing specifics, etc.
- DE_AUTHORIZATION -- The demand-side user has removed the
product from the assortment and wants no further updates sent for the
product.
For this example, assume a demand-side trading partner responded with an
AUTHORIZE response. UCCnet creates a worklist containing this
notification response and delivers it to the AS2 channel server.
- UCCnet performs a compliance check on the data and, if all data
exists in the appropriate formats, creates a worklist containing this
notification response.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependent on platform) that is created during
installation of the solution to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector retrieves the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into a UCCnetDTD_envelope
business object (if iSoft connectivity is used) or a UCCnetTPIDTD_envelope
business object (if TPI connectivity is used). This business object
contains the entire UCCnet message, including each individual data instance
and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the
connector controller, it is converted to a UCCnetDTD_envelope business object
(if iSoft connectivity is used) or a UCCnetTPIDTD_envelope business object (if
TPI connectivity is used). The UCCnetGBO_envelope business object is
converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_to_UCCnetDTD_envelope router and translation maps (if iSoft
connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope router and translation maps (if
TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the AUTHORIZE notification to the
AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM
WebSphere Business Integration Data Handler for XML, which converts it into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
This business object contains the entire UCCnet notification, including each
individual data instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the object
on its From port, 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 does the following:
- Sends email to the recipients configured in the
UCCnet_processWorklist_AUTHORIZATION_RESPONSESObject collaboration object (an
instance of the Notify_by_eMail collaboration template). See the
section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information on how to configure properties
controlling email.
- Logs the event in the audit_log table. See Using the audit_log table for more information on the audit_log table.
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 - ItemPublicationChange detailed in the section ItemPublicationChange workflow: making updated item information available to trading partners and processing their responses -- accomplishes sending these notifications.
Notes:
- The mappings used in processing ItemChange messages use value translation
tables. The IBM WebSphere InterChange Server implements these tables as
cross-references.
- If you are using schema support, refer to the documentation found in ItemChange workflow: updating item information in UCCnet (schema 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 portion of an IBM WebSphere Business Integration Adapter
specific to that ERP. In this example, we use the SAPConnector.
The SAPConnector converts the input from the ERP into a SAP application
specific business object.
- The SAPConnector passes the SAP application specific business object to a
UCCnet_ItemSync collaboration object, first transforming it into a generic
ItemBasic business object with a Update verb by passing it through
the Sa4CwItemBasic input map.
- The UCCnet_ItemSync collaboration object accepts the object on its
From port and checks that required fields contain 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. If all required fields
are not complete, the collaboration object aborts processing and sends an
email to a configured address, as detailed in the section Alerting email recipients of processing errors. For this example, assume all fields are
complete.
- 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 verb to Create and adds it to the PROCESSED_GTIN table, setting
the entry's withdrawn field to N.
Assume for this example 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 delivers the ItemBasic
business object to the AS2 channel connector over its To
port. In the connector controller, it is converted into a
UCCnetDTD_envelope (if iSoft connectivity is used) or a UCCnetTPIDTD_envelope
(if TPI connectivity is used). The ItemBasic business object is
converted by passing through the RouterMap_CwItemBasic_to_UCCnetDTD_envelope
and CwItemBasic_to_UCCnetDTD_envelope_documentCommand_item router and
translation maps (if iSoft connectivity is used) or the
RouterMap_CwItemBasic_to_UCCnetTPIDTD_envelope and
CwItemBasic_to_UCCnetTPIDTD_envelope_documentCommand_item router and
translation maps (if TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the ItemChange XML
message in UCCnet format.
- The AS2 channel connector passes this message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
ItemChange message to UCCnet.
- UCCnet generates and returns to the AS2 channel server an MDN to indicate
successful receipt of the ItemChange message.
- The AS2 channel server delivers the MDN to the AS2 channel
connector.
- The AS2 channel connector sends the MDN to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is
used).
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope (if iSoft
connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope (if
TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the
business object on its From port, identifies it as an MDN, and
dispatches it to its SIMPLE_RESPONSE subdiagram. See the section SIMPLE_RESPONSE subdiagram for more information on this subdiagram.
- The SIMPLE_RESPONSE subdiagram sends email to the recipients configured in
the UCCnet_processWorklist_SIMPLE_RESPONSEObject collaboration object (an
instance of the Notify_by_eMail collaboration template). See the
section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information on how to configure properties
controlling email.
- UCCnet creates a worklist containing an ItemChange notification to
indicate a successful ItemChange.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependent on platform) that is created during
installation of the solution to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector retrieves the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into a UCCnetDTD_envelope
business object (if iSoft connectivity is used) or a UCCnetTPIDTD_envelope
business object (if TPI connectivity is used). This business object
contains the entire UCCnet message, including each individual data instance
and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through either the UCCnetDTD_envelope_to_UCCnetGBO_envelope input
map (if iSoft connectivity is used) or the
UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope (if TPI connectivity is
used).
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the
connector controller, it is converted to a UCCnetDTD_envelope business object
(if iSoft connectivity is used) or a UCCnetTPIDTD_envelope business object (if
TPI connectivity is used). The UCCnetGBO_envelope business object is
converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_to_UCCnetDTD_envelope router and translation maps (if iSoft
connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope router and translation maps (if
TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the ItemChange notification for a
successful ItemChange to the AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM
WebSphere Business Integration Data Handler for XML, which converts it into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
This business object contains the entire UCCnet notification, including each
individual data instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration receives the business
object on its From port, 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. This
on-going workflow, referred to as the ItemPublicationChange workflow, is
continued in the section ItemPublicationChange workflow: making updated item information available to trading partners and processing their responses.
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: updating item information in UCCnet (DTD 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. As a result, the
ItemPublicationChange workflow is described as two subflows:
At this point in processing, the ItemChange workflow has completed and a
UCCnetGBO_envelope business object has arrived in the ITEM_ADD_CHANGE
subdiagram of the UCCnet_processWorklist collaboration object.
The following description shows how the ItemPublicationChange workflow
makes updated item information available to a supplier's demand-side
trading partners:
- The UCCnet_processWorklist collaboration object's ITEM_ADD_CHANGE
subdiagram does the following:
- The UCCnet_processWorklist collaboration object's ITEM_ADD_CHANGE
subdiagram configures the business object so that the router map will select
the correct transformation map.
- The subdiagram sends the ItemPublicationChange request over the
ITEM_ADD_CHANGE port to 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.
See the section ITEM_ADD_CHANGE subdiagram for more information on this subdiagram.
- The AS2 channel connector maps the UCCnetGBO_envelope business object into
a UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
The UCCnetGBO_envelope business object is converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_notification_to_UCCnetDTD_envelope_publishCommand router
and transformation maps (if iSoft connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_notification_to_UCCnetTPIDTD_envelope_publishCommand router
and transformation maps (if TPI connectivity is used). The business
object contains the corresponding ItemPublicationAdd request. This
message includes a request for UCCnet to publish the item to the trading
partners listed in the message.
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the
ItemPublicationChange XML message in UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
ItemPublicationChange message to UCCnet.
- UCCnet generates and sends to the AS2 channel server an MDN indicating
successful receipt of the ItemPublicationChange message.
- The AS2 channel server delivers the MDN to the AS2 channel
connector.
- The AS2 channel connector sends the MDN to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is
used).
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the
business object on its From port, identifies it as an MDN, and
dispatches it to its SIMPLE_RESPONSE subdiagram. See the section SIMPLE_RESPONSE subdiagram for more information on this subdiagram.
- The SIMPLE_RESPONSE subdiagram sends email to the recipients configured in
the UCCnet_processWorklist_SIMPLE_RESPONSEObject collaboration object (an
instance of the Notify_by_eMail collaboration template). See the
section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information on how to configure properties
controlling email.
- UCCnet performs a compliance check on the data. If all the data are
in the correct formats, UCCnet creates a worklist containing the
PUB_RELEASE_DATA_CHANGE notification to indicate a successful
ItemPublicationChange.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependent on platform) that is created during
installation of the solution to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector retrieves the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into a UCCnetDTD_envelope
business object (if iSoft connectivity is used) or a UCCnetTPIDTD_envelope
business object (if TPI connectivity is used). This business object
contains the entire UCCnet message, including each individual data instance
and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the
connector controller, it is converted to a UCCnetDTD_envelope business object
(if iSoft connectivity is used) or a UCCnetTPIDTD_envelope business object (if
TPI connectivity is used). The UCCnetGBO_envelope business object is
converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_to_UCCnetDTD_envelope router and translation maps (if iSoft
connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope router and translation maps (if
TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the PUB_RELEASE_DATA_CHANGE
notification for a successful ItemPublicationChange to the AS2 channel
server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM
WebSphere Business Integration Data Handler for XML, which converts it into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
This business object contains the entire UCCnet notification, including each
individual data instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
(if TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the object
on its From port, identifies it as a PUB_RELEASE_DATA_CHANGE, and
dispatches it to its NEW_ITEM_PUBLICATION_REQUEST subdiagram. See the
section NEW_ITEM_PUBLICATION_REQUEST subdiagram for more information on this subdiagram.
As a result of this subflow of the ItemPublicationChange workflow, updated
item information is made available to a supplier's demand-side trading
partners. The on-going subflow that alerts them of the available
updated information and processes their responses, referred to as the
ItemPublicationChange subflow 2, is continued in the section ItemPublicationChange subflow 2: processing trading partners' responses to updated item information.
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 UCCnet_processWorkflow collaboration object's
NEW_ITEM_PUBLICATION_REQUEST subdiagram logic 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 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.
- Sends the ItemPublicationChange for the GTIN to the demand-side
trading partners identified in the business object. The message is sent
over the NEW_ITEM_PUBLICATION_REQUEST port to 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 AS2 channel connector maps the business object into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
The business object is converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_notification_to_UCCnetDTD_envelope_ publishCommand router
and transformation maps (if iSoft connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_notification_to_UCCnetTPIDTD_envelope_publishCommand router
and transformation maps (if TPI connectivity is used).
- The business object is converted to XML, delivered to the AS2 channel
server, and then to UCCnet.
- 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 user's legacy environment and the demand-side user is ready
to begin trading.
- PEND_PUBLICATION -- The demand-side user 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 user has no interest in the
product.
- PRE_AUTHORIZATION -- The demand-side user wants to begin the process
of integrating the product into its legacy environment. This response
might indicate that the supplier contact the demand-side user to begin the
process of deciding on order quantities, pricing specifics, etc.
- DE_AUTHORIZATION -- The demand-side user has removed the
product from the assortment and wants no further updates sent for the
product.
For this example, assume a demand-side trading partner responded with an
AUTHORIZE response.
- UCCnet performs a compliance check on the data. If all the data
exist in the appropriate formats, then UCCnet creates a worklist containing
the notification response.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependent on platform) that is created during
installation of the solution to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector retrieves the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into a UCCnetDTD_envelope
business object (if iSoft connectivity is used) or UCCnetTPIDTD_envelope
business object (if TPI connectivity is used). This business object
contains the entire UCCnet message, including each individual data instance
and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the
connector controller, it is converted to a UCCnetDTD_envelope business object
(if iSoft connectivity is used) or a UCCnetTPIDTD_envelope business object (if
TPI connectivity is used). The UCCnetGBO_envelope business object is
converted by passing through the
RouterMap_UCCnetGBO_envelope_to_UCCnetDTD_envelope and
UCCnetGBO_envelope_to_UCCnetDTD_envelope router and translation maps (if iSoft
connectivity is used) or the
RouterMap_UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope and
UCCnetGBO_envelope_to_UCCnetTPIDTD_envelope router and translation maps (if
TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the AUTHORIZE notification to the
AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM
WebSphere Business Integration Data Handler for XML, which converts it into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
This business object contains the entire UCCnet notification, including each
individual data instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through the UCCnetDTD_envelope_to_UCCnetGBO_envelope input map (if
iSoft connectivity is used) or the UCCnetTPIDTD_envelope_to_UCCnetGBO_envelope
input map (if TPI connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the object
on its From port, 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 does the following:
- Sends email to the recipients configured in the
UCCnet_processWorklist_AUTHORIZATION_RESPONSESObject collaboration object (an
instance of the Notify_by_eMail collaboration template). See the
section Sending email through UCCnet_processWorklist collaboration object subdiagrams for more information on how to configure properties
controlling email.
- Logs the event in the audit_log table. See Using the audit_log table for more information on the audit_log table.
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: making an item temporarily unavailable to all or selected trading partners (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: making an item permanently unavailable to trading partners (schema 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 portion of an IBM WebSphere Business Integration Adapter
specific to that ERP. In this example, we use the SAPConnector.
The SAPConnector converts the input from the ERP into a SAP application
specific business object.
- The SAPConnector passes the SAP application specific business object to a
UCCnet_ItemSync collaboration object, first transforming it into a generic
ItemBasic business object with an Delist verb by passing it through
the Sa4CwItemBasic input map.
- The UCCnet_ItemSync collaboration object accepts the object on its
From port and checks that required fields contain 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. If all required fields
are not complete, the collaboration object aborts processing and sends an
email to a configured address, as detailed in the section Alerting email recipients of processing errors. For this example, assume 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 delivers the ItemBasic
business object to the AS2 channel connector over its To
port. In the connector controller, it is converted to a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
The ItemBasic business object is converted by passing through the
RouterMap_CwItemBasic_to_UCCnetDTD_envelope and
CwItemBasic_to_UCCnetDTD_envelope_publishCommand_documentIdentifier router and
translation maps (if iSoft connectivity is used) or the
RouterMap_CwItemBasic_to_UCCnetTPIDTD_envelope and
CwItemBasic_to_UCCnetTPIDTD_envelope_publishCommand_documentIdentifier router
and translation maps (if TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the ItemDelist XML
message in UCCnet format.
- The AS2 channel connector passes this message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
ItemDelist message to UCCnet.
- UCCnet generates an MDN to indicate successful receipt of the
ItemDelist message.
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: making an item permanently unavailable to trading partners (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: making an item temporarily unavailable to all or selected trading partners (schema 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 portion of an IBM WebSphere Business Integration Adapter
specific to that ERP. In this example, we use the SAPConnector.
The SAPConnector converts the input from the ERP into a SAP application
specific business object.
- The SAPConnector passes the SAP application specific business object to a
UCCnet_ItemSync collaboration object, first transforming it into a generic
ItemBasic business object with an Withdraw verb by passing it
through the Sa4CwItemBasic input map.
- The UCCnet_ItemSync collaboration object accepts the object on its
From port and checks that required fields contain 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. If all required fields
are not complete, the collaboration object aborts processing and sends an
email to a configured address, as detailed in the section Alerting email recipients of processing errors. For this example, assume 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 action prevents the publication of the item in
response to an incoming INITIAL_ITEM_LOAD_REQUEST. 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 object delivers the ItemBasic
business object to the AS2 channel connector over its To
port. In the connector controller, it is converted into a
UCCnetDTD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIDTD_envelope business object (if TPI connectivity is used).
The ItemBasic business object is converted by passing through the
RouterMap_CwItemBasic_to_UCCnetDTD_envelope and
CwItemBasic_to_UCCnetDTD_envelope_publishCommand_documentIdentifier router and
translation maps (if iSoft connectivity is used) or the
RouterMap_CwItemBasic_to_UCCnetTPIDTD_envelope and
CwItemBasic_to_UCCnetTPIDTD_envelope_publishCommand_documentIdentifier router
and translation maps (if TPI connectivity is used).
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the ItemWithdrawal
XML message in UCCnet format.
- The AS2 channel connector passes this message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
ItemWithdrawal message to UCCnet.
- UCCnet generates and returns to the AS2 channel server an MDN to
indicate successful receipt of the ItemWithdrawal message.
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.
The information in the following sections outlines at a high level how the
Item Synchronization for Suppliers solution handles the workflows that support
the schema-based implementations.
Refer to the Installation guide for detailed information
on creating port connections between collaboration objects and between
collaboration objects and connectors.
Collaboration objects based on the ItemCommandRouter, Notify_by_eMail,,
UCCnet_ItemSync, UCCnet_requestWorklist, UCCnet_processWorklist, or
CIN_CIP_Dispatcher collaboration templates 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 flaws and data
processed. See the section Tracing for detailed information.
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: making a new item available to trading partners and processing their responses , accomplishes sending these notifications.
Notes:
- The mappings used in processing ItemAdd messages use value translation
tables. The IBM WebSphere InterChange Server implements these tables as
cross-references.
- If you are not using schema support, refer to the documentation found in ItemAdd workflow: adding a new item to UCCnet (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 portion of an IBM WebSphere Business Integration Adapter
specific to that ERP. In this example, we use the SAPConnector.
The SAPConnector converts the input from the ERP into a SAP application
specific business object.
- The SAPConnector passes the SAP application specific business object to a
UCCnet_ItemSync collaboration object, first transforming it into a generic
ItemBasic business object with a Create verb by passing it through
the Sa4CwItemBasic input map.
- The UCCnet_ItemSync collaboration object accepts the object on its
From port and checks that required fields contain 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. If all required fields
are not complete, the collaboration object aborts processing and sends an
email to a configured address, as detailed in the section Alerting email recipients of processing errors. For this example, assume 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 identify the ItemAdd transaction processed. See the section Using the audit_log table for more information about the audit_log table.
- The UCCnet_ItemSync collaboration object delivers the ItemBasic business
object to the ItemCommandRouter collaboration object.
- The ItemCommandRouter collaboration object receives the business object on
its From port and determines that it represents an item to be added
to the UCCnet. It them passes the business object to its
TO_RCIR port.
- The ItemBasic business object is passed to the AS2 channel connector where
it is converted into an application specific business object in the connector
controller by either the
CwItemBasic_to_UCCnetXSD_envelope_registerCommand_itemAddChange map or the
CwItemBasic_to_UCCnetTPIXSD_envelope_registerCommand_itemAddChange map,
depending on the connectivity type being used.
- Once the conversion is complete, the business object is passed to the AS2
channel connector agent, which sends it to the IBM WebSphere Business
Integration Data Handler for XML to produce the ItemAdd XML message in UCCnet
format.
- The connector then passes the message to the AS2 channel server.
- The server created the digest, encrypts, and then transmits the ItemAdd
message to UCCnet.
- UCCnet creates a worklist containing the notification response
RCIR_ADD_Response.
- A time-triggered process must be configured to move query command messages
tailored to retrieve specific UCCnet notifications from the following
directory (dependent on platform), which is created during installation of the
solution, and send them to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector retrieves the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into either a
UCCnetXSD_envelope business object (if iSoft connectivity is used) or a
UCCnetTPIXSD_envelope (if TPI connectivity is used). This business
object contains the entire UCCnet message, including each individual data
instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope by one of the
following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the
connector controller, it is converted into either a UCCnetXSD_envelope or a
UCCnetTPIXSD envelope, depending on which connectivity is being used.
The UCCnetGBO_envelope business object is converted by passing through one of
the following translation maps:
- UCCnetGBO_envelope_to_UCCnetXSD_envelope (iSoft connectivity)
- UCCnetGBO_envelope_to_UCCnetTPIXSD_envelope (TPI connectivity)
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, and encrypts and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the RCIR_RESPONSE notification
indicating a successful ItemAdd to the AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into either a
UCCnetXSD_envelope or a UCCnetTPIXSD_envelope business object, depending on
the connectivity being used. The business object contains the entire
UCCnet notification, including each individual data instance and the commands
related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- 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 of the UCCnet_processWorklist
collaboration object.
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 workflows that
accomplish this are described in the section CatalogueItemNotification_Add and CatalogueItemPublication_Add workflows: making a new item available to trading partners and processing their responses.
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: adding a new item to UCCnet (schema 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. At this point in processing, 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 RCIR_RESPONSE notification
inside a UCCnetGBO_envelope business object for the received message.
It logs the notification in the audit_log table. See the section Using the audit_log table for more information on the audit_log table.
- It creates an empty ItemBasic business object and sends it to the
DestinationAppRetrieve port with a retrieve verb.
- The ItemBasic business object that initiated the corresponding RCIR
command, which was sent it to UCCnet, is returned on the
DestinationAppRetrieve port with a Create verb.
- The ItemBasic BO is sent to the RCIR_RESPONSE port with a Create
verb.
-
- When using a supplier-implemented data source pool
-
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port and maps it to a
CatalogueItemNotification_ADD UCCnetGBO_envelope using the
CwItemBasic_to_UCCnetGBO_envelope_notifyCommand_catalogueItem map.
- 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.
- The collaboration object sends a CatalogueItemNotification_ADD (CIN_ADD)
notification out the To port to the AS2 channel connector for each GLN found
in the GLN subscription file.
- The UCCnetGBO_envelope business object is mapped to either a
UCCnetXSD_envelope or UCCnetTPIXSD_envelope business object, depending on the
connectivity being used.
- The AS2 channel connector sends the business objects to the IBM WebSphere
Business Integration Data Handler for XML, which produces the CIN_ADD XML
messages in UCCnet format.
- The AS2 channel connector passes the messages to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts and transmits the
messages to UCCnet.
- UCCnet forwards the CIN_ADD messages to the demand-side trading
partners.
- When using UCCnet as the data source pool
-
- The AS2 channel connector receives the ItemBasic business object and maps
it to a CatalogueItem_ADD UCCnetXSD_envelope or UCCnetTPIXSD_envelope business
object using either
CwItemBasic_to_UCCnetXSD_envelope_publicationCommand_catalogueItem (iSoft) or
CwItemBasic_to_UCCnetTPIXSD_envelope_publicationCommand_catalogueItem
(TPI).
- The AS2 channel connector sends the business objects to the IBM WebSphere
Business Integration Data Handler for XML, which produces the CI_ADD XML
message in UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts and transmits the
message to UCCnet.
- UCCnet returns a catalogue item response to the AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into either a
UCCnetXSD_envelope or a UCCnetTPIXSD_envelope business object, depending on
the connectivity being used. The business object contains the entire
UCCnet notification, including each individual data instance and the commands
related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the business
object on its From port, identifies it as an CI response notification, and
sends it to the PUBLICATION_COMMAND_RESPONSE subdiagram of the
UCCnet_processWorklist collaboration object.
- The PUBLICATION_COMMAND_RESPONSE subdiagram creates an empty ItemBasic
business object and sends it to the DestinationAppRetrieve port with a
retrieve verb
- The ItemBasic business object that initiated the corresponding RCIR
command, which was sent to UCCnet, is returned.
- The returned ItemBasic business object is sent to the
PUBLICATION_CMD_RESPONSE port with a Create verb.
- 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 using the
CwItemBasic_to_UCCnetGBO_env_publicationCommand_catalogueItemPublication
map.
- It uses the business object's category code to retrieve the GLNs of
any subscribed trading partners from the GLN subscription file. This
file is determined by the DISPATCHER_GLN_FILE property.
- The collaboration object sends a CatalogueItemPublication_ADD (CIP_ADD)
notification out the To port to the AS2 channel connector for each GLN found
in the GLN subscription file.
- The UCCnetGBO_envelope is mapped to either a UCCnetXSD_envelope or
UCCnetTPIXSD_envelope business object, depending on the connectivity being
used.
- The AS2 channel connector sends the business objects to the IBM WebSphere
Business Integration Data Handler for XML, which produces the CIP_ADD XML
messages in UCCnet format.
- The AS2 channel connector passes the messages to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts and transmits the
messages to UCCnet.
- UCCnet returns a catalogue item publication response to the AS2 channel
server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into either a
UCCnetXSD_envelope or a UCCnetTPIXSD_envelope business object, depending on
the connectivity being used. The business object contains the entire
UCCnet notification, including each individual data instance and the commands
related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the business
object on its From port, 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 to UCCnetGBO_envelope
CIP response to the CIP_RESPONSE port with a create verb to send a
notification email to the supplier.
- As a result of receiving the CIP_ADD messages, UCCnet sends out a
CatalogueItemNotification to each subscribing demand-side trading partner for
whom a CIP was received.
- At this point, the trading partners can respond with any of the following
Catalogue Item Confirmation responses:
- REVIEW
- This state is used to tell parties that an item is being reviewed by the
retailer.
- REJECTED
- This state is used to tell parties that an item is rejected and that no
additional information is requested at this time.
- ACCEPTED
- This state is used to tell initiators that an item has been accepted by
the retailer, but has not yet been synchronized. This state is similar
to a DTD-based UCCnet PRE-AUTHORIZATION.
- SYNCHRONISED
- This state is used to tell initiators that an item has been accepted by
the retailer and will be synchronized. This state is similar to a
DTD-based UCCnet AUTHORIZE.
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 a SYNCHRONISED notification to indicate a successful
receipt.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependent on platform), which is created during
installation of the solution, to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector receives the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML.
- The IBM WebSphere Business Integration Data Handler for XML converts the
worklist query command into either a UCCnetXSD_envelope business object or a
UCCnetTPIXSD_envelope business object, depending on the connectivity being
used. This business object contains the entire UCCnet message,
including each individual data instance and the command related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing it through one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the connector
controller, it is converted to either a UCCnetXSD_envelope business object or
a UCCnetTPIXSD_envelope business object, depending on the connectivity being
used.
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the SYNCHRONISED notification to
the AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into either a
UCCnet_XSD_envelope business object or a UCCnet_TPIXSD_envelope business
object, depending on the connectivity being used. This business object
contains the entire UCCnet notification, including each individual data
instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing it through one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The AS2 channel connector delivers the business object to the
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the object on its
From port, identifies it as a CATALOGUE_ITEM_CONFIRMATION response, and
dispatches it to its CATALOGUE_ITEM_CONFIRMATION subdiagram.
- The CATALOGUE_ITEM_CONFIRMATION subdiagram carries out the following
tasks:
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: making updated item information available to trading partners and processing their responses , accomplish sending these notifications.
Notes:
- The mappings used in processing ItemChange messages use value translation
tables. The IBM WebSphere InterChange Server implements these tables as
cross-references.
- If you are not using schema support, refer to the documentation found in ItemChange workflow: updating item information in UCCnet (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 portion of an IBM WebSphere Business Integration Adapter
specific to that ERP. In this example, we use the SAPConnector.
The SAPConnector converts the input from the ERP into a SAP application
specific business object.
- The SAPConnector passes the SAP application specific business object to a
UCCnet_ItemSync collaboration object, first transforming it into a generic
ItemBasic business object with an Update verb by passing it through
the Sa4CwItemBasic input map.
- The UCCnet_ItemSync collaboration object accepts the object on its
From port and checks that required fields contain 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. If all required fields
are not complete, the collaboration object aborts processing and sends an
email to a configured address, as detailed in the section Alerting email recipients of processing errors. For this example, assume all fields are
complete.
- 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 verb to Create and adds it to the PROCESSED_GTIN table, setting
the entry's withdrawn field to N.
Assume for this example 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 ItemBasic business
object through its To port to the ItemCommandRouter collaboration
object.
- The ItemCommandRouter collaboration object receives the business object on
its From port, determines that it represents an ItemChange and
sends it to its TO_RCIR port.
- The ItemBasic business object is sent to the AS2 channel connector.
- The connector controller converts it into an application specific business
object by using one of the following maps:
- CwItemBasic_to_UCCnetXSD_envelope_registerCommand_itemAddChange (iSoft
connectivity)
- CwItemBasic_to_UCCnetTPIXSD_envelope_registerCommand_itemAddChange (TPI
connectivity)
It then sends the business object to the IBM WebSphere Business
Integration Data Handler for XML, which produces the ItemChange XML message in
UCCnet format.
- The AS2 channel connector passes this message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
ItemChange message to UCCnet.
- UCCnet creates a worklist containing an RCIR_CHANGE_Response notification
to indicate a successful ItemChange.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependant on platform), which is created during
installation of the solution, to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
The JTextRWLConnector polls its event directory for any
worklist query commands that might have been delivered. See the section
Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector retrieves the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into either a
UCCnetXSD_envelope, or a UCCnetTPIXSD_envelope application specific business
object, depending on whether iSoft connectivity or TPI connectivity is
used. This business object contains the entire UCCnet message,
including each individual data instance and the commands related to
it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the connector
controller it is converted to a UCCnetXSD_envelope or UCCnetTPIXSD_envelope by
passing through one of the following maps:
- UCCnetGBO_envelope_to_UCCnetXSD_envelope (iSoft connectivity)
- UCCnetGBO_envelope_to_UCCnetTPIXSD_envelope (TPI connectivity)
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist, which contains the RCIR_CHANGE_Response
notification for a successful ItemChange, to the AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into a
UCCnetXSD_envelope application specific business object or a
UCCnetTPIXSD_envelope, depending on the connectivity type being used.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the business
object on its From port, identifies it as an 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. This
is accomplished by the CatalogueItemNotification_Change and
CatalogueItemPublication_Change workflows, detailed in the sectionCatalogueItemNotification_Change and CatalogueItemPublication_Change workflow: making updated item information available to trading partners and processing their responses.
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 the
CatalogueItemNotification_Change and CatalogueItemPublication_Change
workflows, updated item information that was passed to UCCnet through the
ItemChange workflow (detailed in the section ItemChange workflow: updating item information in UCCnet (schema 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.
At this point in processing, 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 RCIR_RESPONSE notification
inside a UCCnetGBO_envelope business object for the received message.
It logs the notification in the audit_log table. See the section Using the audit_log table for more information on the audit_log table.
- It creates an empty ItemBasic business object and sends it to the
DestinationAppRetrieve port with a retrieve verb.
- The ItemBasic business object that initiated the corresponding RCIR
command, which was sent it to UCCnet, is returned on the
DestinationAppRetrieve port with an Update verb.
- The ItemBasic BO is sent to the RCIR_RESPONSE port with an Update
verb.
-
- When using a supplier-implemented data source pool
-
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port and maps it to a
CatalogueItemNotification_ADD UCCnetGBO_envelope using the
CwItemBasic_to_UCCnetGBO_envelope_notifyCommand_catalogueItem map.
- 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.
- The collaboration object sends a CatalogueItemNotification_CHANGE
(CIN_CHANGE) notification out the To port to the AS2 channel connector for
each GLN found in the GLN subscription file.
- The UCCnetGBO_envelope business object is mapped to either a
UCCnetXSD_envelope or UCCnetTPIXSD_envelope business object, depending on the
connectivity being used.
- The AS2 channel connector sends the business objects to the IBM WebSphere
Business Integration Data Handler for XML, which produces the CIN_CHANGE XML
messages in UCCnet format.
- The AS2 channel connector passes the messages to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts and transmits the
messages to UCCnet.
- UCCnet forwards the CIN_CHANGE messages to the demand-side trading
partners.
- When using UCCnet as the data source pool
-
- The AS2 channel connector receives the ItemBasic business object and maps
it to a CatalogueItem_CHANGE UCCnetXSD_envelope or UCCnetTPIXSD_envelope
business object using either
CwItemBasic_to_UCCnetXSD_envelope_publicationCommand_catalogueItem (iSoft) or
CwItemBasic_to_UCCnetTPIXSD_envelope_publicationCommand_catalogueItem
(TPI).
- The AS2 channel connector sends the business objects to the IBM WebSphere
Business Integration Data Handler for XML, which produces the CI_ADD XML
message in UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts and transmits the
message to UCCnet.
- UCCnet returns a catalogue item response to the AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into either a
UCCnetXSD_envelope or a UCCnetTPIXSD_envelope business object, depending on
the connectivity being used. The business object contains the entire
UCCnet notification, including each individual data instance and the commands
related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the business
object on its From port, identifies it as an CI response notification, and
sends it to the PUBLICATION_COMMAND_RESPONSE subdiagram of the
UCCnet_processWorklist collaboration object.
- The PUBLICATION_COMMAND_RESPONSE subdiagram creates an empty ItemBasic
business object and sends it to the DestinationAppRetrieve port with a
retrieve verb
- The ItemBasic business object that initiated the corresponding RCIR
command, which was sent to UCCnet, is returned.
- Since this is an item chance, no CatalogueItemPublications are
sent. The PUBLICATION_COMMAND_RESPONSE subdiagram sends to
UCCnetGBO_envelope CI response to the CI_RESPONSE port with a create verb to
send a notification email to the supplier.
- The list of suppliers that receive a notification is determined based on
the CIP messages previously 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
- This state is used to tell parties that an item is being reviewed by the
retailer.
- REJECTED
- This state is used to tell parties that an item is rejected and that no
additional information is requested at this time.
- ACCEPTED
- This state is used to tell initiators that an item has been accepted by
the retailer, but has not yet been synchronized. This state is similar
to a DTD-based UCCnet PRE-AUTHORIZATION.
- SYNCHRONISED
- This state is used to tell initiators that an item has been accepted by
the retailer and will be synchronized. This is similar to the UCCnet
Authorization.
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 the SYNCHRONISED notification response.
- A chronologically triggered process must be configured to move query
command messages tailored to retrieve specific UCCnet notifications from the
following directory (dependent on platform), which is created during
installation of the solution, to the event directory of the
JTextRWLConnector:
- On Windows systems:
..\WebSphereICS\UCCnet\UCCnetMessages\Source
- On UNIX systems:
../WebSphereICS/UCCnet/UCCnetMessages/Source
- Note:
- This process is not part of the solution and must be customized by the
user. The installation path is dependent on the path set when the
solution is installed.
- The JTextRWLConnector polls its event directory for any
worklist query commands that have been delivered. See the section Polling UCCnet for worklists for more information on this process.
- The JTextRWLConnector receives the worklist query command from its
event directory and sends it to the IBM WebSphere Business
Integration Data Handler for XML.
- The IBM WebSphere Business Integration Data Handler for XML converts the
worklist query command into either a UCCnetXSD_envelope business object or a
UCCnetTPIXSD_envelope business object, depending on the connectivity being
used. This business object contains the entire UCCnet message,
including each individual data instance and the command related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The JTextRWLConnector passes the business object to a
UCCnet_requestWorklist collaboration object.
- The UCCnet_requestWorklist collaboration object receives the
UCCnetGBO_envelope business object on its From port and passes it
to the AS2 channel connector over its To port. In the connector
controller, it is converted to either a UCCnetXSD_envelope business object or
a UCCnetTPIXSD_envelope business object, depending on the connectivity being
used.
- The AS2 channel connector sends the business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the XML message in
UCCnet format.
- The AS2 channel connector passes the message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
message to UCCnet.
- UCCnet delivers the worklist containing the SYNCHRONISED notification to
the AS2 channel server.
- The AS2 channel server delivers the notification to the AS2 channel
connector.
- The AS2 channel connector sends the notification to the IBM WebSphere
Business Integration Data Handler for XML, which converts it into either a
UCCnet_XSD_envelope business object or a UCCnet_TPIXSD_envelope business
object, depending on the connectivity being used. This business object
contains the entire UCCnet notification, including each individual data
instance and the commands related to it.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through one of the following input maps:
- UCCnetXSD_envelope_to_UCCnetGBO_envelope (iSoft connectivity)
- UCCnetTPIXSD_envelope_to_UCCnetGBO_envelope (TPI connectivity)
- The AS2 channel connector delivers the business object to the
UCCnet_processWorklist collaboration object.
- The UCCnet_processWorklist collaboration object receives the object on its
From port, identifies it as a CATALOGUE_ITEM_CONFIRMATION response, and
dispatches it to its CATALOGUE_ITEM_CONFIRMATION subdiagram.
- The CATALOGUE_ITEM_CONFIRMATION subdiagram carries out the following
tasks:
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: making an item temporarily unavailable to all or selected trading partners (schema 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: making an item permanently unavailable to trading partners (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 portion of an IBM WebSphere Business Integration Adapter
specific to that ERP. In this example, we use the SAPConnector.
The SAPConnector converts the input from the ERP into a SAP application
specific business object.
- The SAPConnector passes the SAP application specific business object to a
UCCnet_ItemSync collaboration object, first transforming it into a generic
ItemBasic business object with an Delist verb by passing it through
the Sa4CwItemBasic input map.
- The UCCnet_ItemSync collaboration object accepts the object on its
From port and checks that required fields contain 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. If all required fields
are not complete, the collaboration object aborts processing and sends an
email to a configured address, as detailed in the section Alerting email recipients of processing errors. For this example, assume 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 through its To port to the ItemCommandRouter collaboration
object.
- The ItemCommandRouter receives the business object on its From port, and
determines that it is a delist.
- The ItemCommandRouter sends the ItemBasic business object through its
ToCIN_CI port.
-
- When using a supplier-implemented data source pool
- A Notify_by_eMail collaboration object receives the ItemBasic business
object and sends a note to the supplier saying that the CI_DELIST is
unsupported.
- When using UCCnet as the data source pool
-
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port.
- The collaboration object maps the ItemBasic business object to a
UCCnetXSD_envelope or UCCnetTPIXSD_envelope business object, depending on the
connectivity type used, using the map defined by its collaboration
parameters.
- The collaboration object uses the category code from the new
UCCnetXSD_envelope or UCCnetTPIXSD_envelope to retrieve the GLNs of any
trading partners that subscribe to it. The collaboration object
retrieves the trading partner subscription list from the GLN subscription
file, defined by the CIN_DISPATCHER_GLN_FILE property.
- The collaboration object sends a CatalogueItemNotification_DELIST
(CIN_DELIST) business object to the AS2 connector for each GLN found in the
GLN subscription file.
- At the connector, they are converted into either UCCnetXSD_envelope
business objects or into UCCnetTPIXSD_envelope business objects, depending on
the connectivity being used.
- The AS2 channel connector sends each business object to the IBM WebSphere
Business Integration Data Handler for XML, which produces the
CatalogueItemNotification_delist XML message in UCCnet format.
- The AS2 channel connector passes this message to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts, and transmits the
CatalogueItemNotification_delist message to UCCnet.
- UCCnet generates an MDN to indicate successful receipt of the
CatalogueItemNotification_delist message.
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: making an item permanently unavailable to trading partners (schema 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: making an item temporarily unavailable to all or selected trading partners (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 portion of an IBM WebSphere Business Integration Adapter
specific to that ERP. In this example, we use the SAPConnector.
The SAPConnector converts the input from the ERP into a SAP application
specific business object.
- The SAPConnector passes the SAP application specific business object to a
UCCnet_ItemSync collaboration object, first transforming it into a generic
ItemBasic business object with a Withdraw verb by passing it through the
Sa4CwItemBasic input map.
- The UCCnet_ItemSync collaboration object accepts the object on its From
port and checks that required fields contain 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. If all required fields
are not complete, the collaboration object aborts processing and sends an
email to a configured address, as detailed in the section Alerting email recipients of processing errors. For this example, assume 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 delivers the ItemBasic business
object to the From port of the ItemCommandRouter collaboration
object by sending it out from its To port.
- The ItemCommandRouter collaboration object uses a combination of the verb
and the DeleteFlag attribute of the ItemBasic business object to determine
that the item is being withdrawn.
- The ItemCommandRouter sends the ItemBasic business object out through its
ToCIN_CI port
-
- When using a supplier-implemented data source pool
-
- The CIN_CIP_Dispatcher collaboration object receives the ItemBasic
business object on its From port and maps it to a
CatalogueItemNotification_WITHDRAW UCCnetGBO_envelope using the
CwItemBasic_to_UCCnetGBO_envelope_notifyCommand_catalogueItem map.
- 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.
- The collaboration object sends a CatalogueItemNotification_WITHDRAW
(CIN_WITHDRAW) notification out the To port to the AS2 channel connector for
each GLN found in the GLN subscription file.
- The UCCnetGBO_envelope business object is mapped to either a
UCCnetXSD_envelope or UCCnetTPIXSD_envelope business object, depending on the
connectivity being used.
- The AS2 channel connector sends the business objects to the IBM WebSphere
Business Integration Data Handler for XML, which produces the CIN_WITHDRAW XML
messages in UCCnet format.
- The AS2 channel connector passes the messages to the AS2 channel
server.
- The AS2 channel server creates the digest, encrypts and transmits the
messages to UCCnet.
- UCCnet forwards the CIN_WITHDRAW messages to the demand-side trading
partners.
- When using UCCnet as the data source pool
- A Notify_by_eMail collaboration object receives the ItemBasic business
object and sends a note to the supplier saying the the CI_DELIST 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.
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. The GTIN and WITHDRAWN
columns are added to the table via 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:
- An audit_log table that receives log entries from each participant
component in the solution. A sample entry includes the following
fields. Sample values are included for each:
- LOG_SEQ_NO -- 1
- LOG_SOURCE_NAME -- UCCnet2
- GLN_CODE -- NA
- SOURCE_SYSTEM
- PRODUCT_ID -- 2050000000454
- VERB_NAME -- Create
- TRANS_ID -- SAPConnector_1015606877187_1
- TRANS_TYPE -- UCCnet_processWorklist
- TRANS_STATUS -- ITEM_ADD_CHANGE
- MSG_FILEPATH_TEXT --
C:\IBM\WebSphereICS\UCCnet-1051628537493.bo
- LOG_DTTM -- May 5, 2003 1:44:56 PM
- A logging framework that is utilized by IBM WebSphere Business Integration
Collaborations and Adapters to log critical events to the audit_log
table.
- An audit log merge process that periodically sweeps the TPI server log for
new entries, which are added to the unified audit_log table. The iSoft
Peer-to-Peer Agent logs are not swept for new entries.
- A report generation facility to support data analysis and
visualization.
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
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
See the Installation guide for installation
instructions.
- Note:
- After these columns are in place, the table must be populated
manually through methods provided by the individual database.
UCCnet never spontaneously sends notification messages; it must
be polled for them via query command messages tailored to retrieve the
specific UCCnet notifications.
A chronologically triggered process must be configured to move your
query command messages to the event directory of the
JTextRWLConnector. This process is not part of the solution and must be
customized by the user. The JTextRWLConnector polls its event directory
for any worklist query commands that might have been delivered at a polling
interval, which is set by the user. When the JTextRWLConnector finds a
worklist query command, it sends it to the IBM WebSphere Business Integration
Data Handler for XML, which converts it into a UCCnetXXX_envelope
business object (if iSoft connectivity is used) or
UCCnetTPIXXX_envelope business object (if TPI connectivity is
used).
- Note:
- In this and the following example names, the variable XXX
specifies the XML definition type used (DTD or XSD).
This business object contains the entire UCCnet message, including each
individual data instance and the commands related to it.
The JTextRWLConnector then passes this business object to a
UCCnet_requestWorklist collaboration object, which passes it to the AS2
channel server for transmission to UCCnet. UCCnet responds with the
appropriate worklist, which initiates ongoing workflows in the
solution.
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).
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 to it a UCCnetGBO_envelope business
object. This business object is created from the following
process:
- The AS2 channel connector receives the UCCnet worklist document (envelope)
from the AS2 channel server.
- The AS2 channel connector sends the document to the IBM WebSphere Business
Integration Data Handler for XML, which converts it into a
UCCnetXXX_envelope business object (if iSoft connectivity is used)
or UCCnetTPIXXX_envelope business object (if TPI connectivity is
used). In these business object names, XXX is either
DTD or XSD, depending on whether you are using a DTD XML
definition or a schema-based XML definition.
- The business object is converted to a UCCnetGBO_envelope business object
by passing through an input map of the form
UCCnetXXX_envelope_to_UCCnetGBO_envelope (if iSoft connectivity is
used) or UCCnetTPIXXX_envelope_to_UCCnetGBO_envelope (if TPI
connectivity is used).
- The AS2 channel connector delivers the business object to a
UCCnet_processWorklist collaboration object.
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 called
UCCnet_processWorklist_AUTHORIZATION_RESPONSESObject, which sends an email to
selected recipient(s). 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 called
UCCnet_processWorklist_CATEGORY_ADD_CHANGEObject. 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 called
UCCnet_processWorklist_CATALOGUE_ITEM_CONFIRMATIONObject, 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 called
UCCnet_processWorklist_DEAD_LETTER_PUB_RECEIPTObject, which sends an email to
selected recipient(s). 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: making a new item available to trading partners. 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 ItemPublicationAdd or ItemPublicationChange request over
the ITEM_ADD_CHANGE port to 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 first subflow of either the
ItemPublicationAdd or ItemPublicationChange workflow, as detailed in the
sections ItemPublicationAdd subflow 1: making a new item available to trading partners and ItemPublicationChange subflow 1: making updated item information available to trading partners.
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: processing trading partners' responses to a new item and ItemPublicationChange subflow 2: processing trading partners' responses to updated item information.
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 a Notify_by_eMail
collaboration object to send a notification email to the supplier, 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.
- 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.
When using CIN operation,
- 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.
The follow-up workflow is the CatalogueItemNotification_Add or
CatalogueItemNotification_Change workflow, as detailed in the sections CatalogueItemNotification_Add and CatalogueItemPublication_Add workflows: making a new item available to trading partners and processing their responses and CatalogueItemNotification_Change and CatalogueItemPublication_Change workflow: making updated item information available to trading partners and processing their responses. 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 called
UCCnet_processWorklist_SIMPLE_RESPONSEObject, which sends an email to selected
recipient(s). 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
UCCnet_processWorklist_UNKNOWN_MESSAGESObject, which sends an email to
selected recipient(s). 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 called UCCnet_processWorklist_UNKNOWN_RESPONSEObject, which sends an
email to selected recipient(s). 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. Several of these
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, as follows:
- CATEGORY_ADD_CHANGE subdiagram -- Instantiates a collaboration object
called UCCnet_processWorklist_CATEGORY_ADD_CHANGEObject.
- AUTHORIZATION_RESPONSES subdiagram -- Instantiates a collaboration
object called UCCnet_processWorklist_AUTHORIZATION_RESPONSESObject.
- DEAD_LETTER_PUB_RECEIPT subdiagram -- Instantiates a collaboration
object called UCCnet_processWorklist_DEAD_LETTER_PUB_RECEIPTObject.
- CATALOGUE_ITEM_CONFIRMATION subdiagram -- Instantiates a
collaboration object called
UCCnet_processWorklist_CATALOGUE_ITEM_CONFIRMATIONObject
- SIMPLE_RESPONSE subdiagram -- Instantiates a collaboration object
called UCCnet_processWorklist_SIMPLE_RESPONSEObject.
- UNKNOWN_MESSAGES subdiagram -- Instantiates a collaboration
object called UCCnet_processWorklist_UNKNOWN_MESSAGESObject.
- UNKNOWN_RESPONSE subdiagram -- Instantiates a collaboration object
called UCCnet_processWorklist_UNKNOWN_RESPONSEObject.
Each of these objects based on the Notify_by_eMail collaboration template
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 recipient(s) 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.
