(Enterprise)

Procurement system integration

WebSphere Commerce provides the capability to integrate with procurement systems. This capability enables WebSphere Commerce customers to participate as suppliers in the procurement system's marketplace, increase sales, and enhance their business-to-business presence on the Web. WebSphere Commerce provides an extensible and customizable functionality in such a way that one can extend either the messages or the business logic. WebSphere Commerce supports two modes of integration to procurement systems: Local catalog mode, and Punch-out catalog mode.

Note: The WebSphere Commerce procurement system integration does not support the EDP system.

Local catalog mode

In local catalog mode, suppliers replicate their catalog on the procurement system. The buyers can browse the catalog and construct a shopping cart without connecting to the supplier's WebSphere Commerce site.

Purchasing flow using the local catalog mode

In local catalog mode, suppliers replicate their catalog on the procurement system. The following steps represent the purchasing flow:

1. Buyers browse the catalog on the procurement system and create an order.

2. The procurement system sends the OrderRequest message to WebSphere Commerce with the buyer and supplier logon and user IDs, the order, and billing and shipping information.

3. The OrderRequest message is mapped to the BatchOrderRequest command, which creates a new order in batch processing.

4. After the OrderRequest message is authenticated and processed, the OrderResponse message is sent to the procurement system and indicates the success or failure of the order.

Punch-out catalog mode

In Punch-out catalog mode, suppliers maintain a single catalog within WebSphere Commerce, and use it to enable Web presence and participation in the procurement system's network.

Purchasing flow using the punch-out catalog mode

In punch-out catalog mode, suppliers maintain a single catalog within WebSphere Commerce and use it to enable Web presence in the procurement system's network. The following steps represent the purchasing flow:

1. The Buyer selects the supplier on the procurement system and the PunchOutSetupRequest message is sent to WebSphere Commerce.

2. The PunchOutSetupRequest message is mapped to the PunchOut setup command.

3. The PunchOutSetup command calls the AuthenticationHelper command to authenticate the buyer and suppliers user and logon IDs. A task command is called depending on the authentication mode.

4. After successful authentication, the PunchOutSetup command calls the RegisterRequisitioner task command to check whether the requisitioning user is registered with the system. If the user does not exist the user is registered as a new user and given the role of Procurement Buyer.

5. Use the PunchOutSetupResponse message, WebSphere Commerce sends the CatalogDisplay URL and information needed to bind the session back to the procurement system.

6. The procurement system launches a new browser window using the PunchOutCatalogDisplay command and the catalog is displayed to the Buyer to begin browsing and purchasing.

7. The Buyer checks out the order and the content is put into the PurchaseOrder message and sent to the procurement system for approval.

8. The procurement system sends the OrderRequest message to WebSphere Commerce to create the order after it is approved by an approver on the procurement system.

Types of communication in procurement systems

Customers can choose to operate in either local or punch-out catalog mode using the communication of choice with their procurement system. The procurement systems use two different types of communication protocols. WebSphere Commerce provides the infrastructure (commands, database schema) to support both types of protocols.

Two-step mode

This protocol is used by procurement systems that use XML/HTTP or some other XML messages. The XML messages are used for initial setup, authentication, and registration of requisitioning users that belong to the buyer organization. Once the initial tasks are completed, a browser window is launched where the buyer can complete their shopping cycle.

One-step mode

This protocol is used by procurement systems that use browser URL requests for initial setup and authentication, as well as for buyers to complete their shopping cycle. An example of this protocol is OCI protocol.

Order Management subsystem extensions for procurement

In WebSphere Commerce, the database schema supports additional information for orders and order items from buying organizations, and order status information from the fulfillment center. The database schema was extended for procurement to capture the order and order item information that is sent by the procurement system on the buyer's behalf.

Two tables were created to extend the capturing of order information:

• ORDMEEXTN

• ORDIMEEXTN

The ORDRMEEXTN table extends the capability of the ORDERS table, and the ORDIMEEXTN extends the capability of the ORDERITEMS table. These tables can be customized to capture additional information.

Note: The Order Management subsystem cannot send orders to the procurement system for approval or process orders that are sent from the procurement system. These actions are supported by the SubmitShoppingCart, SendShoppingCart, and BatchOrderRequest commands.

Catalog subsystem extensions for procurement

Some procurement systems require classification codes for catalog entries under different classification standards such as the UNSPC (United Nations Standard Product and Services classification).

To accommodate this requirement, the following tables are added to the catalog subsystem:

• CLASIFCODE

• CLSFCODEDS

• CATCLSFCOD

WebSphere Commerce catalog and order management subsystems use the UN/CEFACT (United Nations Center for Trade Facilitation and Electronic Business) standard unit of measurement (UOM) code for quantities and pricing calculations. The QTYUNIT table lists the UN/CEFACT UOM codes used, however, procurement system protocols such as MySAP OCI require the ISO standard UOM codes in the messages.

To provide one-to-one mapping between the UN/CEFACT codes in the QTYUNIT table and the UOM codes under other standards, the QTYUNITMAP database table was added to the catalog subsystem. UOM UN/CEFACT codes for catalog entries in the QTYUNITMAP table.

Contract and pricing support for procurement systems (Enterprise)

WebSphere Commerce allows buyers the ability to purchase under different contracts with different terms and conditions. Customized pricing can be set up under any of the contracts. We can use the default contract or create our own contracts.

The BUYSUPMAP table lists the relationships between buyers and suppliers. This table includes the CONTRACT_ID and MBRGROUP_ID columns. The CONTRACT_ID column identifies the contract used by the buyer and the supplier. The MBRGROUP_ID column identifies the member groups to be assigned to a requisitioner when they are registered.

If you use the default contract, we can perform the following tasks:

• Create a member group for each group of future requisitioning users from one organization or unit.

• Create terms and conditions policies for pricing and product sets. Associate these terms and conditions with the PARTICIPNT database table.

Note: The CONTRACT_ID value for the default contract is NULL.

If we create our own contract, we can perform the following tasks:

• Create a contract between the buyer and supplier

• Create a member group for future requisitioners from an organization or unit.

• Make the member group a participant of the contract.

• Register the buyer and supplier with the contract and the member group in the BUYSUPMAP table.

Messages and commands for procurement

In order to integrate with procurement systems, WebSphere Commerce uses a series of messages and commands. There are five messages in total, two inbound messages to WebSphere Commerce from the procurement system and three outbound messages from WebSphere Commerce to the procurement system. Each message is associated with a command, as shown in the following table.

Message Name	Command	Direction	Response
PunchOutSetupRequest	PunchOutSetup	Inbound	PunchOutSetupResponse
OrderRequest	BatchOrderRequest	Inbound	OrderResponse
PunchOutSetupResponse	PunchOutSetup	Outbound
PurchaseOrderMessage (The order sent to the procurement system for approval.)	PrepareOrder	Outbound
OrderResponse	BatchOrderRequest	Outbound

When we use the punch-out integration, we might get an exception that is related to the missing dynamic cache instance. We can create or update cacheinstances.properties with services/cache/WCSharedDistributedMap instance, or create this cache instance in WebSphere Application Server Administration Console. For example,

cache.instance.0=/services/cache/WCSharedDistributedMap 
cache.instance.0.cacheSize=20000
#cache.instance.0.memoryCacheSizeInMB=10
cache.instance.0.enableDiskOffload=false
cache.instance.0.flushToDiskOnStop=false
cache.instance.0.useListenerContext=false
cache.instance.0.replicationType=1
cache.instance.0.enableCacheReplication=true
cache.instance.0.replicationDomain=WC_Cluster_DRS
cache.instance.0.disableDependencyId=false
cache.instance.0.filterTimeOutInvalidation=true
cache.instance.0.filterInactivityInvalidation=true
cache.instance.0.filterLRUInvalidation=true
cache.instance.0.ignoreValueInInvalidationEvent=true
cache.instance.0.disableTemplatesSupport=true
cache.instance.0.useServerClassLoader=true

Update the cache.instance.0.replicationDomain=WC_Cluster_DRS value according to the environment configuration.

• Configure WebSphere Commerce to communicate with a procurement system
  WebSphere Commerce supports integration with a procurement system.

• Configure a buyer organization that uses a procurement system
  WebSphere Commerce can be integrated with procurement systems. This page explains how to configure the buyer organization when integrating with a procurement system.

• Configure the cookie for procurement
  WebSphere Commerce uses a generated encrypted cookie to bind the session between the Punch-out setup phase where the requisitioning user's (if the user is new) authentication and registration is performed, and the catalog shopping phase where the procurement system launches a new browser window for the requisitioning user.

• Access control for procurement systems
  In WebSphere Commerce access control policies are used to determine what roles can have access to which parts of the system. For procurement systems, there must be a role with the authority to register the requisitioning users on the fly who belong to a buyer organization, as well as another role to send the order back to the procurement system.

• Adding a new message mapper for procurement
  Procurement systems that use the XML/HTTP protocol need to have a message mapper in order to communicate successfully with WebSphere Commerce.

• Enable NLS for XML messages
  We can provide procurement integration with NLS support when the XML/HTTP protocol is used.

• Creating messages for procurement integration message keys
  Procurement integration provides the infrastructure for sending error messages back to the procurement system when authorization has failed or a request cannot be completed due to other error conditions. The actual error messages sent back to the procurement system need to be customized, and the property file containing these messages is not provided by WebSphere Commerce.

Related tasks
Enable NLS for XML messages
Creating messages for procurement integration message keys