Setting up the sample

Setting up the sample involves setting up WebSphere Partner Gateway, WebSphere MQ, and WebSphere InterChange Server. The following sections describe how to do this.

Setting up WebSphere Partner Gateway

The following procedure describes how to set up WebSphere Partner Gateway so that it has the settings and resources it needs to run all the scenarios of the PIP sample. The setup for System B and C is the same except where noted.

  1. Start WebSphere Partner Gateway and log in to the Community Console as Hub Admin.
  2. Create a Community Manager profile to represent WebSphere Partner Gateway and a Community Participant profile for the other system. For example, on System B, you create a Community Participant profile for System C. For information on creating profiles, see the Hub Configuration Guide.
  3. Create the gateways for the profiles:

    See the Hub Configuration Guide for more information on creating gateways.

    1. Click Account Admin > Profiles > Community Participant.
    2. Search for the Community Manager profile you created.
    3. Click on the View details icon next to the profile.
    4. Click Account Admin > Profiles > Gateways.
    5. Click Create.
    6. In the Gateway Detail section, type or select the values shown in Table 8:

      Use the default values for all other parameters.

      Table 8. Community Manager gateway values
      Parameter Value to type or select

      Address

      The URL for the JNDI service that stores the JMS objects required by WebSphere Partner Gateway to route the documents. For WebSphere MQ JMS, the file system JNDI can be leveraged. If the file system JNDI is leveraged, the format of the address is as follows:

      file:///<user_defined_MQ_JNDI_bindings_path>

      The directory contains the bindings file for the file-based JNDI. This field is required.

      Authentication Required

      If enabled, user name and password are supplied with JMS or SMTP messages.

      Auto Queue

      If enabled, documents are placed in a temporary repository if the gateway is placed offline. If disabled and the gateway is placed offline, the document fails to route and an error occurs.

      Configuration Point Handlers

      Used to specify which handlers are used for preprocessing and postprocessing.

      Description

      Optional description of the gateway.

      Gateway Name

      Name used to identify the gateway.

      Note: Gateway Name is a user-defined free format field. While uniqueness is not required, users should use different names for individual gateways to avoid potential confusion.

      JMS Factory Name

      Name of the Java(TM) class the JMS provider will use to generate connection to the JMS queue.

      JMS JNDI Factory Name

      Factory name used to connect to the name service.

      JMS Message Class

      Class of message.

      JMS Message Type

      Type of JMS message.

      JMS Queue Name

      Queue name where JMS messages are stored.

      Number of Threads

      Number of threads allocated for routing a document. Default value is 3. This parameter is available to Hub Admin users only.

      Online / Offline

      Indicate whether the gateway is online or offline. If offline, documents are queued until the gateway is placed online.

      Password

      Password for secure access through the participant firewall.

      Provider URL Packages

      Name of classes or JAR file that Java uses to understand JMS Context URL.

      Retry Count

      Maximum number of times the system tries to send a document before it fails. Default value is 3.

      Retry Interval

      Amount of time that the gateway should wait in between retry attempts. Default value is 300 (5 minutes).

      Status

      Indicates whether the gateway is enabled or disabled. If disabled, documents passing through the gateway fail processing.

      Transport

      Protocol for routing documents.

      User Name

      User name for secure access through the participant firewall.

      Validate Client IP

      Validates the IP address of the sending partner before processing the document. Used with the Gateway that is selected as a source Gateway for a connection.

      Note:
      Refer to the Enterprise Integration Guide for more information on back-end configuration using JMS with WebSphere MQ 5.3.
    7. Click Save.
    8. Create the gateway for the Community participant in the same way but use the following values for the Gateway Detail section:
      Table 9. Community Participant gateway values
      Parameter Value to type or select
      Gateway name Type any name for the gateway
      Transport HTTP/1.1
      Target URI Type the URL for the other WebSphere Partner Gateway system. That is, if you are creating System B, type the URL for System C. Example: http://<IPAddress of System C:57080>/bcgreceiver/submit/test

      For the other parameters, use the default values.

    9. Click Save.
  4. Set the gateways as default gateways:
    1. Click Account Admin > Profiles > Community Participant.
    2. Search for the Community Manager profile you created.
    3. Click on the View details icon next to the profile.
    4. Click Account Admin > Profiles > Gateways.
    5. In the Default Gateway List window, click View Default Gateways.
    6. For all of the gateway types, select the gateway you created.
    7. Set the default gateways for the Community Participant profile in the same way.
  5. Upload the following PIP document flow packages:

    Refer to the Hub Configuration Guide for information on uploading packages. If packages for the other RNIF version or another version of the PIP have already been loaded, set the Overwrite Data parameter to Yes.

    You can verify that the packages have been uploaded by clicking Hub Admin > Hub Configuration > Document Flow Definition. Click All and look for the following in the RNIF (V02.00) and Backend Integration packages:

  6. Create interactions for the PIPs:
    1. Click Hub Admin > Hub Configuration > Document Flow Definition.
    2. In the Manage Document Flow Definitions window, click Manage Interactions.
    3. In the Manage Interactions window, click Create Interaction.
    4. Expand the Document Flow Definition trees by clicking All in the Source tree and in the Target tree.
    5. In the Source tree, select the radio button for Action: Purchase Order Request Action in the following context:
      Package: RNIF (V02.00)  
          Protocol: RosettaNet (V02.00)
              Document Flow: 3A4 (V02.02) "Request Purchase Order"  
                  Activity: Request Purchase Order
    6. In the target tree, select the radio button for Action: Purchase Order Request Action in the following context:
      Package: Backend Integration (1.0)  
          Protocol: RNSC (1.0)
              Document Flow: 3A4 (V02.02) "Request Purchase Order"  
                  Activity: Request Purchase Order
    7. In the Action field, select Bi-directional Translation of RosettaNet and RosettaNet Service Content with Validation.
    8. Click Save.
    9. Repeat steps a-h to create an interaction in the other direction. That is, the RNIF Package is the target and the Backend Integration package is the source.
    10. Repeat steps a-i to create interactions for the following actions:
      • 3A4 Purchase Order Confirmation Action.
      • 3C3 Invoice Notification Action
      • 0A1 Failure Notification Action
  7. Create an interaction for XMLEvent.
    1. Click Hub Admin > Hub Configuration > Document Flow Definition.
    2. In the Manage Document Flow Definitions window, click Manage Interactions.
    3. In the Manage Interactions window, click Create Interaction.
    4. Expand the Document Flow Definition trees by clicking All in the Source tree and in the Target tree.
    5. In the Source tree, select the radio button for Document Flow: XMLEvent (1.0) in the following context:
      Package: Backend Integration (1.0)  
          Protocol: XMLEvent (1.0)
    6. In the Target tree, select the radio button for Document Flow: XMLEvent (1.0) in the following context:
      Package: Backend Integration (1.0)  
          Protocol: XMLEvent (1.0)
    7. In the Action field, select Pass Through.
    8. Click Save.
  8. Create an interaction for XMLEvent to 0A1 RNSC.
    1. Click Hub Admin > Hub Configuration > Document Flow Definition.
    2. In the Manage Document Flow Definitions window, click Manage Interactions.
    3. In the Valid Document Flow Interactions window, click Create Interaction.
    4. Expand the Document Flow Definition trees by clicking All in the Source tree and in the Target tree.
    5. In the Source tree, select the radio button for Document Flow: XMLEvent (1.0) in the following context:
      Package: Backend Integration (1.0)  
          Protocol: XMLEvent (1.0)       
    6. In the target tree, select the radio button for Action: Failure Notification Action in the following context:
      Package: Backend Integration (1.0)  
          Protocol: RNSC (1.0)
             Document Flow: 0A1 (V02.00) "Notification of Failure"
                Activity: Distribute Notification of Failure
    7. In the Action field, select Bi-directional Translation of RosettaNet and xml with validation.
    8. Click Save.
  9. Create targets for the transport protocols:
    1. Click Hub Admin > Hub configuration > Targets.
    2. Click Create Target.
    3. In the Target Name field, type a name.
    4. In the Transport field, select HTTP/S.
    5. In the Target Configuration section, type the URI for the Receiver that handles HTTP messages such as /bcgreceiver/Receiver.
    6. Select the appropriate Gateway Type. (Example: Production).
    7. Click Save.
    8. Click Hub Admin > Hub configuration > Targets.
    9. Click Create Target.
    10. In the Target Name field, type a name.
    11. In the Transport field, select JMS.
    12. In the Target Configuration section, select the appropriate Gateway Type. (Example: Production).
    13. Type the appropriate values for the following fields:
      • JMS Provider URL
        Example: file:///export/jndi/myctx
      • JMS Queue Name
        Example: RECEIVERQ
      • JMS Factory Name
        Example: myqcf
      • JNDI Factory Name
        Example: com.sun.jndi.fscontext.RefFSContextFactory
      Note:
      Refer to the Integration Overview Guidefor more information on back-end configuration using JMS with WebSphere MQ 5.3.
    14. Click Save.
  10. Refer to the Hub Configuration Guide for information on enabling security.
  11. Enable the B2B capabilities for the profiles.
    1. Click Account Admin > Profiles > Community Participant.
    2. Search for the Community Manager profile you created.
    3. Click on the View details icon next to the profile.
    4. Click Account Admin > Profiles > B2B Capabilities.
    5. Expand the Document Flow Definition tree by clicking All.
    6. Ensure that the Community Manager has the B2B capabilities for the RNIF (V02.00) and Backend Integration (1.0) packages enabled. If the packages are inactive (neither enabled or disabled), active them by clicking the icon in the Set Source and Set Target columns.
    7. Repeat the previous step for the RosettaNet (V02.00) protocol under the RNIF (V02.00) package and the XMLEvent (1.0) and RNSC (1.0) protocols under the Backend Integration (1.0) package. Do the same for the following Document Flows:
      • Document Flow: XMLEvent (1.0) under Protocol: XMLEvent (1.0)
      • Document Flow: 3A4 (V02.02) under Protocol: RNSC (1.0)
      • Document Flow: 3C3 (V01.01) under Protocol: RNSC (1.0)
      • Document Flow: 0A1 (V02.00) under Protocol: RNSC (1.0)
      • Document Flow: 3A4 (V02.02) under Protocol: RosettaNet (V02.00)
      • Document Flow: 3C3 (V01.01) under Protocol: RosettaNet (V02.00)
      • Document Flow: 0A1 (V02.00) under Protocol: RosettaNet (V02.00)
    8. Repeat a-f for the Community Participant profile.
  12. Create participant connections.
    1. Click Account Admin > Participant Connections.
    2. In the Source, select the Community Manager profile.
    3. In the Target, select the Community Participant profile.
    4. Click Search.
    5. Click Activate for the following interaction:
      Table 10.
      Source Target
      Package: Backend Integration (1.0) Protocol: XMLEvent (1.0) Document Flow: XMLEvent (1.0) Package: Backend Integration (1.0) Protocol: RNSC (1.0) Document Flow: 0A1 (V02.00) Activity: Distribute Notification of Failure (N/A)
    6. Enable all other interactions on the window.
    7. In the Source, select the Community Participant profile.
    8. In the Target, select the Community Manager profile.
    9. Click Search.
    10. Click Activate for the following interaction:
      Table 11.
      Source Target
      Package: Backend Integration (1.0) Protocol: XMLEvent (1.0) Document Flow: XMLEvent (1.0) Package: Backend Integration (1.0) Protocol: XMLEvent (1.0) Document Flow: XMLEvent (1.0)
    11. Enable all other interactions on the window.

Setting up WebSphere MQ

To set WebSphere MQ to support the sample, create the following queues in the Queue Manager:

Consult the WebSphere MQ documentation for information on how to create the queues.

Setting up the WebSphere InterChange Server

The following procedure describes how to set up WebSphere InterChange Server so that it has the settings and resources it needs to run all the scenarios of the PIP sample. For more information on any of the steps in the procedure, see the WebSphere InterChange Server documentation.

  1. Once the WebSphere InterChange Server is running, start the system manager and create an integration component library (ICL).
  2. Import the contents of the ICS Repository into the newly created ICL.
  3. Create the Database Connection Pool at Initiator side:
    1. Create a database for Requestor and create the RNState table using the BCG_pip_sample_table_creation.sql script.
    2. In the ICL, right click the Database Connection Pool folder and select Create new Database Connection Pool.
    3. Specify the database, database driver (DB2), DBConnection name, login, password, and maximum number of connections.
    4. In the new connection pool section, right click and select New Connection Pool.
    5. Specify the name of the pool as CWLDPool and set the minimum number of connections to 1.
    6. Click OK and then click Finish to create the Database Connection Pool.
  4. Create the Database Connection Pool at Responder side:
    1. Create second database for Responder and create the RNState table using the BCG_pip_sample_table_creation.sql script.
    2. In the ICL, right click the Database Connection Pool folder and select Create new Database Connection Pool.
    3. Specify the database, database driver (DB2), DBConnection name, login, password, and maximum number of connections.
    4. In the new connection pool section, right click and select New Connection Pool.
    5. Specify the name of the pool as CWLDPool1 and set the minimum number of connections to 1.
    6. Click OK and then click Finish to create the Database Connection Pool
  5. Create the Connectors:
    1. In the ICL, right click the Connectors folder and select Create new connector.
    2. The Connector Configurator window appears. In the New Connector panel, select Cancel.
    3. Select File > Open > From File.
    4. In the File Open dialog, select the connector configuration file for the JMS Connector and click Open.
    5. Repeat a-d to create the Port Connector.
    6. Open the JMS Connector and select File > Save As > To Project. Save a copy of the JMS Connector using the name JMSConnector1.
  6. Configuring the JMS Connectors
    1. In the ICL, open the Connectors folder and double-click the JMS Connector.
    2. In the Connector Configurator window, select the Connector-Specific Properties tab.
    3. Set values for the following attributes:
      Table 12.
      Attribute Value
      CTX_InitialContextFactory com.sun.jndi.fscontext.RefFSContextFactory
      ReplyToQueue The name of the queue in which the JMS Connector puts the messages
      UnsubscribedQueue CWLD_Unsubscribed
      CTX_ProviderURL The URL of the JMS context provider
      InProgressQueue CWLD_InProgress
      DataHandlerConfigMO MO_DataHandler_Default
      MessageResponseResultProperty CWLD_Result
      DataHandlerMimeType Attachment
      QueueConnectionFactoryName The queue connection factory created in WebSphere MQ
      ErrorQueue CWLD_Error
      InputQueue The name of the queue that the JMS Connector polls for incoming messages
    4. Select the Supported Business Objects tab.
    5. Select the following Business Objects from the list and enable Agent Support for each one:
      • BCG_Pip3A4PurchaseOrderRequest
      • BCG_Pip3A4PurchaseOrderConfirmation
      • BCG_Pip3C3InvoiceNotification
      • BCG_Pip0A1FailureNotification
      • BCG_EventNotification
      • MO_DataHandler_Default
    6. Select the Trace/Log Files tab and configure the log and trace files.
    7. Repeat a-f for JMSConnector1
  7. In the MO_DataHandler_Default business object, add the Attachment attribute and set its BO Type as MO_DataHandler_DefaultAttachmentConfig.
  8. Configure the Port Connector:
    1. In the ICL, open the Connectors folder and double-click the Port Connector.
    2. In the Connector Configurator window, select the Supported Business Objects tab.
    3. Select the following Business Objects from the list and enable Agent Support for each one:
      • BCG_Pip3A4PurchaseOrderRequest
      • BCG_Pip3A4PurchaseOrderConfirmation
      • BCG_Pip0A1FailureNotification
      • BCG_Pip3C3InvoiceNotification
      • BCG_EventNotification
    4. Select the Trace/Log Files tab and configure the log and trace files.
  9. Compile the collaboration templates by right clicking the Collaboration Templates folder and selecting Compile All.
  10. Create the collaboration objects
    1. Right-click the Collaboration Objects folder and select Create new collaboration object.
    2. Select the template and provide a name for the collaboration object name. Click Next.
    3. Bind the ports with the appropriate connectors given in the following table:
      Table 13. Port-connector bindings for BCG_Pip3A4_Request collaborations
      Port Connector
      RequestFromBackend PortConnector
      RequestToWBIC JMSConnector
      EventToWBIC JMSConnector
      EventFromBackend PortConnector
      ResponseFromWBIC JMSConnector
      ResponseToBackend PortConnector
    4. Click Next.
    5. Specify the e-mail notification address, set the system trace level to 2, and set the collaboration trace level to 5. Click Next.
    6. Specify values for the following collaboration properties, using the default values where available:
      • DB_CONN_POOL_NAME
      • ATTACHMENT_FILE_DIR
    7. Click 'Finish' to complete creation of collaboration object.
    8. Repeat a-g for the following collaborations
      Table 14. Port-connector bindings for BCG_Pip3A4_Response collaborations
      Port Connector
      RequestFromWBIC JMSConnector1
      RequestToBackend PortConnector
      EventFromBackend PortConnector
      EventFromWBIC JMSConnector1
      ResponseFromBackend PortConnector
      ResponseToWBIC JMSConnector1
      Table 15. Port-connector bindings for BCG_Pip3C3_Notifier collaborations
      Port Connector
      RequestFromBackend PortConnector
      RequestToWBIC JMSConnector
      EventToWBIC JMSConnector
      EventFromBackend PortConnector
      Table 16. Port-connector bindings for BCG_Pip3C3_Receiver collaborations
      Port Connector
      RequestFromWBIC JMSConnector1
      RequestToBackend PortConnector
      EventFromBackend PortConnector
      EventFromWBIC JMSConnector1
      Table 17. Port-connector bindings for BCG_0A1FailureNotification collaboration for Requestor
      Port Connector
      NOFFromWBIC JMSConnector
      NOFToBackend PortConnector
      EventFromWBIC JMSConnector
      EventToBackend PortConnector
      Table 18. Port-connector bindings for BCG_0A1FailureNotification collaboration for Responder
      Port Connector
      NOFFromWBIC JMSConnector1
      NOFToBackend PortConnector
      EventFromWBIC JMSConnector1
      EventToBackend PortConnector
      Note:
      Two 0A1 Failure Notification collaboration objects are needed; one for the initiator side and another for the responder side.
      Initiator side 0A1 collaboration: One end connects to the buyer's back-end system and the other end connects to WebSphere Partner Gateway through WebSphere BI adapters, i.e. JMSConnector.
      Receiver/Responder side 0A1 collaboration: One end connects to the receiver's back-end system and the other end connects to WebSphere Partner Gateway through WebSphere BI adapters, i.e. JMSConnector1. Change the value of the property DB_CONN_POOL_NAME to CWLDPool1.
  11. Deploy the ICL into the ICS Repository
    1. Open the User Projects folder.
    2. Right-click Interchange Server Projects and select New User Project.
    3. Type a name for the project.
    4. In the Available Integration Component Libraries drop down list, select the ICL you created.
    5. Click Finish. This associates the project with the ICL.
    6. In InterChange Servers, connect to the ICS Server.
    7. Right-click the server name and select Add User Project. Select the project you created.
    8. Right-click the server name and select Deploy Projects.
    9. Select the entire project and click Next.
    10. Click Next.
    11. Select the folder for the project and click Finish. This deploys the project on the server.
  12. Restart the InterChange Server.
  13. In a DB2 command window, run the DB creation scripts (db2RNtable_create.sql).
  14. Verify that the scripts created the RNState table.
  15. Start the JMS adapters. Ensure that the JMS queues are properly configured.
  16. Start Monitor.exe and verify that the collaborations and connectors are active.

Running Scenario 1

To run Scenario 1, do the following:

  1. Start the VT connector and define a profile for the Port Connector. Select File > Connect Agent to begin simulating the agent.
  2. Load the sample 3A4 request object (PIP3A4Request.bo) and update the following fields in the test BO:
  3. Send it in asynchronous mode.
  4. Open the log viewer and load the InterChange Server trace file. Search for the following text:
    Collaboration Success: Collaboration Name {The collaboration
    name}, Scenario Name SendRequest, BLOCK Name SendBO.

    This indicates that the 3A4 request has been successfully posted to the JMS connector.

  5. Verify that the WebSphere Partner Gateway on the buyer's side has received the 3A4 request and sent it to the WebSphere Partner Gateway instance configured as the seller's gateway.
  6. The Port Connector receives the 3A4 request message. This is the 3A4 request at the seller's back-end process. Select the request and click Reply success.
  7. Load the 3A4 response object (PIP3A4Response.bo) and update the following fields in the test BO:
  8. Send it in asynchronous mode.
  9. Open the log viewer and load the InterChange Server trace file. Search for the following text:
    Collaboration Success: Collaboration Name {The collaboration 
    name}, Scenario Name SendResponse, BLOCK Name SendBO.

    The Port Connector receives the 3A4 response message is received in the Port Connector. This is the 3A4 response at the buyer's back-end process. Select the response and click Reply success.

Running Scenario 2

To run Scenario 2, run Scenario 1 and then do the following:

  1. Load the PIP3A4Cancel.bo and update the following fields in the test BO:
  2. Send it in asynchronous mode.
  3. Open the log viewer and load the InterChange Server trace file. Search for the following text:

    Collaboration Success: Collaboration Name {The collaboration name}, Scenario Name SendEvent, BLOCK Name SendEvent.

    This indicates the event message has been successfully posted to the JMS connector.

  4. The buyer's WebSphere Partner Gateway instance receives the event message. The instance sends a PIP 0A1 message to the seller's gateway.
  5. The Port Connector receives the PIPA1 message.

Running Scenario 3

To run Scenario 3, do the following:

  1. Start the VT connector and define a profile for the Port Connector. Select File > Connect Agent to begin simulating the agent.
  2. Load the sample 3C3 request object (PIP3C3Request.bo) with the URI of the attachment or with a default attachment BO or both. Update the following fields in the test BO:
  3. Send it in asynchronous mode.
  4. Open the log viewer and load the InterChange Server trace file. Search for the following text:

    Collaboration Success: Collaboration Name {The collaboration name}, Scenario Name SendRequest, BLOCK Name SendBO.

    This indicates the 3C3 request has been successfully posted to the JMS connector.

  5. Verify that the WebSphere Partner Gateway instance on the buyer's side has received the 3C3 request and sent it to the trading partner (in this case the WebSphere Partner Gateway instance configured as the seller's gateway).
  6. The 3C3 request message must reach the responder's gateway and the seller process. The collaboration at the seller side decodes the attachment and writes it to a file mentioned in the collaboration properties, and this URI is set in the business object and sent to back end.
  7. The Port Connector receives the 3C3 request message. This is the 3C3 request at the seller's back-end process. Select the request and click Reply success.

Copyright IBM Corp. 2003, 2005