Usecases and Tutorials

This help includes information on the integrations that are possible between webMethods.io B2B and other products.

Use Cases - Exchanging EDI documents with an AS2 Channel

The following use cases address the runtime aspects of using various combinations of AS2 channel configurations for partners to exchange documents with each other.

These use cases assume that webMethods.io B2B sends a functional acknowledgment when one partner receives a document from another.

webMethods.io B2B automatically detects the exchange documents between partners and generates the functional acknowledgment for each of the inbound documents of partners while processing them. After the functional acknowledgment is generated, webMethods.io B2B sends it to the intended partner using the AS2 out channel. The use cases utilize plain content. Plain EDI content means document content that is not signed, encrypted, or verified.

Ensure to complete the prerequisites mentioned below before you allow partners to exchange EDI documents.

Before You Begin

To start exchanging EDI documents with an AS2 inbound channel

  1. Create the AS2 inbound and AS2 outbound channels for each of the partners.
  2. Create profiles for partners for whom you want to facilitate document exchange.
  3. Ensure that you have created an EDIINT AS2 identity type and identity value in the partner profile of business partners for whom you want to facilitate document exchange over an AS2 channel. The EDIINT AS2 identity type is required in addition to the existing identity type to facilitate the recognition of business partners.
  4. Associate the AS2 inbound and AS2 outbound channels with the newly created partners.
  5. Create a partner user each and associate the partner users with the newly created partner profiles.
  6. Inform the partners to share their AS2 inbound channel endpoint URLs along with partner user credentials with the business partners with whom they want to exchange business documents.

Business Partner Sends Plain EDI content to Another Partner Through webMethods.io B2B

When a partner(TrinityMetalCorp) sends plain EDI content by using an AS2 inbound channel to another partner (Bridgestone), webMethods.io B2B recognizes the document, identifies, and splits the EDI document into Envelope, Group, and Transaction.

webMethods.io B2B also ensures that it sends the corresponding Functional Acknowledgment to the partner(TrinityMetalCorp) using the partner’s preferred outbound channel.

If you have configured a specific processing rule to process specific types of EDI content, webMethods.io B2B applies that processing rule and completes the processing of the document.

Flow of the activities when a partner sends plain EDI content to another partner

A Business Partner Sends EDI Content and Requests a SYNC MDN from Another Partner Through webMethods.io B2B

When a partner (TrinityMetalCorp) sends EDI content by using an AS2 inbound channel requesting for a SYNC MDN from another partner (Bridgestone), the document passes through webMethods.io B2B. webMethods.io B2B recognizes the document, identifies, and splits the EDI document into Envelope, Group, and Transaction.

webMethods.io B2B also ensures that it sends the corresponding EDIINT SYNC MDN and Functional Acknowledgment to the partner using the partner’s preferred outbound channel.

If you have configured a specific processing rule to process specific types of EDI content, webMethods.io B2B applies that processing rule. It routes the document from the sender to the receiver and during this process, webMethods.io B2B creates an SYNC MDN and sends it to the receiver.

Flow of the activities when a partner sends plain EDI content requesting a SYNC MDN

A Business Partner Sends EDI Content and Requests an Asynchronous MDN from Another Partner Through webMethods.io B2B

When a partner (TrinityMetalCorp) sends the EDI content by using an AS2 inbound channel requesting for an Asynchronous MDN, another partner (Bridgestone), the document passes through webMethods.io B2B. webMethods.io B2B recognizes the document, identifies, and splits the EDI document into Envelope, Group, and Transaction.

webMethods.io B2B also ensures that it sends the corresponding EDIINT ASYNC MDN by using the Asynchronous MDN URL that is set in AS2 outbound channel of the partner. Functional Acknowledgment is also sent to the partner using the partner’s preferred outbound channel.

If you have configured a specific processing rule to process specific types of EDI content, webMethods.io B2B applies that processing rule. It routes the document from the sender to the receiver and during this process, webMethods.io B2B creates an ASYNC MDN and sends it to the receiver.

Flow of the activities when a partner sends EDI content requesting a ASYNC MDN

Changing the user status of a B2B Document

You can create an integration in webMethods.io Integration Flow Editor by using the ChangeUserStatusOfB2BTransactions recipe, and change the user status in a B2B transaction.

The ChangeUserStatusOfB2BTransactions recipe uses the predefined operations defined in the webMethods.io B2B application to help you create a business integration. This business integration resides on webMethods.io Integration and you can invoke it by using the processing rule action from the webMethods.io B2B product instance. The integration input pipeline for this recipe is pre-loaded with the input signature needed to interpret a transaction request payload coming from a webMethods.io B2B product instance, and the output pipeline is constructed with the signature that the webMethods.io B2B product instance understands.

The use case starts when an inbound document arrives in webMethods.io B2B and the corresponding integration is invoked through a processing rule. The use case ends when you see the changed user status for that transaction in the Transactions page of webMethods.io B2B product instance. In case an integration fails to execute successfully, the integration returns an appropriate error to the webMethods.io B2B product instance.

Work Flow

The following diagram depicts the work flow of the recipe:

The following sequence diagram depicts the flow of control from webMethods.io B2B to webMethods.io Integration and back:

User Roles and Privileges

Before You Begin

Changing the User Status of a Business Document Using webMethods.io Integration Flow Editor Recipe

  1. On the webMethods.io Integration product instance, go to Recipes.
  2. Go to Flow services, and type B2B in the search box to see the ChangeUserStatusOfB2BTransactions recipe, click Use.
  3. Select a project and the application account to connect to the webMethods.io B2B product instance and click Next.
  4. Type a name for your integration along with a description, and click Finish.

Step 1: Change the userStatus of the Transaction

Modify the existing user status as follows:

  1. In the changeUserStatus operation, click and select Map input and output.
  2. In changeUserStatus Input of the Pipeline Data wizard, double-click on the userStatus field, set the desired string as the value you want to see for a transaction on the webMethods.io B2B product instance, and click Finish.

Step 2: Construct a success message on updating the userStatus of the transaction

If the update succeeds, add a new responseMessage variable in the Pipeline Output. Type an appropriate success message and click Apply.

Step 3: Route the success message to the transaction on webMethods.io B2B product instance

In the generateResponse operation, double-click the readContentAs field and set how you want the input content to be interpreted. Valid values are string and bytes.

Step 4: Error handling: userStatus update failure scenario

If the userStatus update fails (or fails to mark Integration Execution as failed in webMethods.io B2B product instance), modify the existing message in the responseMessage field to an appropriate failure message in the Pipeline Output.

Step 5: Route the failed update of the userStatus to the webMethods.io B2B product instance

The generateResponse operation routes the responseMessage to the webMethods.io B2B product instance. On webMethods.io B2B, go to Monitoring > Transactions and click to see the newly set user status in the webMethods.io Integration orchestration for the corresponding transactions.

Step 6: Error handling: Integration execution failure scenario

In case the execution of the integration fails, set the HTTP status code to 500.

The HTTP error status code is sent back to the integration call made by the processing rule from a webMethods.io B2B product instance.

Common Error Scenarios

The error scenarios are as follows:

Next Steps

For the successful completion of the use case, ensure that all the B2B assets you create on the webMethods.io Integration and webMethods.io B2B product instances are in enabled state.

Routing EDI Documents In and Out of webMethods.io B2B

Summary

You can create an integration in webMethods.io Integration Flow services by using the receiveEDI850Send855B2BTransactions recipe. The recipe receives an EDI purchase order (X12 4010 850) document from a trading partner from webMethods.io B2B, and sends an EDI purchase order acknowledgment (X12 4010 855) back to the trading partner through webMethods.io B2B.

The receiveEDI850Send855B2BTransactions recipe uses the predefined operations defined in the webMethods.io B2B and Electronic Data Interchange applications on webMethods.io Integration Flow services to help you create a business integration. The integration input pipeline for this recipe is pre-loaded with the input signature required to interpret a transaction payload coming from a webMethods.io B2B product instance and the output pipeline is constructed with the signature that the webMethods.io B2B product instance understands.

In this use case, an FTP back-end system generates the purchase order and a custom purchase order XML is used to depict the mapping in the input and output pipelines.

The use case starts when an inbound purchase order (X12 4010 850) document arrives in webMethods.io B2B from a trading partner and the corresponding integration is invoked through a processing rule. The use case ends when the trading partner receives the EDI purchase order acknowledgment (X12 4010 855) document for the purchase order it sent initially.

You can view the purchase order receipt and purchase order acknowledgment transactions in the Transactions page of webMethods.io B2B.

Business Document Flow

User Roles and Privileges

Before You Begin

Routing a Business Document To and From a Trading Partner

  1. On the webMethods.io Integration product instance, go to Recipes.
  2. Go to Flow services, and type B2B in the search box to see the receiveEDI850Send855B2BTransactions recipe, click Use.
  3. Select a project and the application account to connect to the webMethods.io B2B product instance, along with FTP account details, and click Next.
  4. Type a name for your integration along with a description, and click Finish.

    The following image shows the recipe flow:

Step 1: Parse the content received from webMethods.io B2B product instance and generate the required output

In the webMethods.io B2B application, click icon and select the appropriate account details for the parseContent predefined operation.

Ensure that the content field of the Pipeline Input is mapped with the inputContent of the parseContentInput.

Step 2: Extract the interchange control and group headers from the 850 EDI message

Click icon and select Map Input and Output of the processEnvelope operation. Ensure that the outputContent is mapped to the ediMessage.

Step 3: Convert the X12 4010 850 EDI message to the native document type on webMethods.io Integration

In the Pipeline Input, ediMessage is automatically mapped to the ediMessage of the convertEDIMessageToDocument Input.

Step 4: Transform the pipeline to map X12 4010 850 Purchase Order to a compatible format

In the following example, the X12 4010 850 purchase order is mapped with a purchase order in XML format.

Step 5: Convert the X12 4010 850 Purchase Order XML to XML stream

The X12 4010 850 Purchase Order XML in the Pipeline Input is mapped to the documentToXMLStream Input.

Step 6: Send the XML stream to the back-end system

In this example, the orchestration uses an FTP server as the back-end system.

In the Pipeline Input, map the xmlStream to the contentStream of the putFile Input.

Step 7: Transform the pipeline by mapping the XML stream

In the Pipeline Input, map the appropriate custom document fields to the sender and receiver fields in the Pipeline Output.

Step 8: Simulate the generation of the Purchase Order Acknowledgment and convert it to an XML stream

Generate the purchase order acknowledgment in your back-end system and convert it to an XML stream.

Step 9: Write custom logic to send the generated Purchase Order XML to the FTP server (back-end system)

In this example, inputStream of the Pipeline Input is mapped to the outputStream of the putFile Input of the FTP server.

Step 10: Retrieve the Purchase Order Acknowledgment XML from the FTP Server (back-end system)

In this example, remoteFile of the Pipeline Input is mapped to the remoteFile of the getFile Input.

Step 11: Convert the X12 4010 855 Purchase Order Acknowledgment from XML stream to string

Convert the purchase order acknowledgment in your back-end system from a stream to a string.

Step 12: Transform the pipeline by adding a variable

Add itemsAck variable to the Pipeline Output.

The xmlStringToDocument service specifies the need to add this variable to the pipeline output.

Step 13: Convert the Purchase Order Acknowledgment string to a native Purchase Order Acknowledgment on webMethods.io Integration

Map the appropriate fields from the Pipeline Input to the xmlStringToDocument Input .

Step 14: Map the Purchase Order Acknowledgment to a native EDI X12 4010 855 document on webMethods.io Integration

Map the appropriate fields from the Pipeline Input to the convertDocumentToEDIMessage Input.

Step 15: Add a group envelope to the generated EDI X12 4010 855 message

Map the appropriate fields from the Pipeline Input to theaddGroupEnvelope Input .

Step 16: Add an interchange control envelope

Map the appropriate fields from the Pipeline Input to theaddInterchangeEnvelope Input .

Step 17: Send the EDI X12 4010 855 Purchase Order Acknowledgment response to webMethods.io B2B

Map the appropriate fields from the Pipeline Input to the sendtoB2B Input. The submit operation sends the document back to the webMethods.io B2B instance in a signature that it can interpret.

Step 18: Clear the pipeline data

Select the variables in the Pipeline Input, click icon > and click Finish.

Step 19: Return an appropriate error message if the integration execution fails

If the integration execution fails, return an appropriate message to the processing rule integration call you made initially. The message is either displayed on the Course of transaction, or is tracked as a task for a transaction if you have used the reliable execution mode.

Error Scenarios You Might Encounter

Next Steps

For the successful completion of the use case, ensure the following:

Receiving an EDI file in webMethods.io B2B using FTP

Exchanging RNIF Payload with Attachments Along with Payload Validation

When a partner (sender) wants to send a PIP 2A9 request with an attachment and send it to another partner over an RNIF-OUT channel. And the receiver, in turn sends a PIP 2A9 response with attachment synchronously over the same connection. WebMethods.io B2B validates the payload before it sends it and after it receives it as well.

Consider two partners, car-steering supplier(enterprise-sender) and car-seat supplier(receiver).

The following image illustrates the exchange:

Before You Begin

You need the following design-time assets at sender’s side:

You need the following design-time assets at receiver’s side:

On the Sender’s (car_steering_supplier) Side

  1. A PIP2A9Request document is submitted to webMethods.io B2B (Enterprise car_steering_supplier) from webMethods.io Integration.

  2. The enterprise sender car_steering_supplier sends this document over an RNIF Outbound channel using RNIF-partner-specific TPA(Payload validation = Outbound set in TPA) using a custom processing rule: Devlier2A9WithAttachmentToCar_seat_supplier.

    The payload is validated by webMethods.io B2B before it is sent.

    The RNIF PIP2A9Request was sent to car_seat_supplier.

At the Receiver’s (car_seat_supplier) End

  1. The receiver car_seat_supplier receives a PIP2A9 request with attachments from car_steering_supplier over synchronous RNIF IN channel as shown in the following images:

    The RNIF document is received as shown in the following image:

    The incoming payload is validated by webMethods.io B2B as follows:

  2. The Transaction summary displays the RNIF PIP2A9Response document details that are sent by car_seat_supplier.

    The content of the document is as follows:

    The content is received with the attachments highlighted in the following image:

  3. Generated PIP2A9Response with attachments is received by Enterprise car_steering_supplier from partner car_seat_supplier.

    The attachments are highlighted as follows:

    With this, the sender’s payload is validated by webMethods.io B2B before it is sent and validated at the receiver’s when it is received.

Exchanging Flat Files

webMethods.io B2B identifies inbound Flat Files based on the key-value pairs you define. You can define these as custom properties in the Advanced configurations of the inbound channel and subsequently add them as either identifiers or attributes in the corresponding Flat Files you create.

In this use case, an incoming sample.txt Flat File payload is processed through both the HTTP-IN channel.

User Roles and Privileges

webMethods.io B2B instance with administrator privileges.

Before You Begin

You need the following design-time assets:

Runtime Behavior of Flat Files Received Through HTTP-IN Channel

  1. In the Advanced tab of the HTTP-IN channel, under Custom properties, add the key-value pairs with which you want webMethods.io B2B to recognize the inbound payload.

    For example, key1, key2, key3, key4, and key5 are added as custom properties.

    Note: You must add the keys for the payload to get recognized. Values are not mandatory.

  2. Add a Flat File document and add the appropriate key-value pairs as identifiers.

    For example, key1, key2, and key3 are added as identifiers.

  3. Add a Flat File document and add the appropriate key-value pairs as attributes you want to extract so that you can perform further transformations.

    For example, key4 and key5 are added as attributes.

  4. Receive sample.txt through the HTTP-IN channel.

    The payload in sample.txt is recognized based on the custom properties you defined.

  5. Define a processing rule based on which you want the Flat File to be routed and transformed further.

Runtime Behavior of Flat Files Received Through SFTP-IN Channel

  1. In the Advanced tab of the SFTP-IN channel, under Custom properties, add the key-value pairs with which you want webMethods.io B2B to recognize the inbound payload.

    For example, key1, key2, key3, key4, key5 are added as custom properties.

    Note: You must add a value to each of the keys you add, for the payload to get recognized for an SFTP channel. Values are mandatory.

  2. Add a Flat File document and add the appropriate key-value pairs as identifiers.

    For example, key1, key2, and key3 are added as identifiers.

  3. Add a Flat File document and add the appropriate key-value pairs as attributes you want to extract so that you can perform further transformations.

    For example, key4 and key5 are added as attributes.

  4. Receive sample.txt through the SFTP-IN channel.

  5. Define a processing rule based on which you want the Flat File to be routed and transformed further.

Next Steps

You currently cannot do the following with Flat Files:

Exchanging RNIF Payload Two - way PIP

webMethods.io B2B facilitates the exchange of PIP messages over RNIF 2.0 channel. Exchanging a document in a two-way PIP process with RNIF 2.0 involves receiving and sending action messages and acknowledgments from both the partners.

When a partner (sender) sends a PIP 3A4 Purchase Order request to another partner (receiver) over an RNIF OUT channel using transport version 2.0, the receiver in turn sends receipt acknowledgment to the sender.

The receiver generates 3A4 Purchase Order confirmation and sends it back to the sender as a response using an RNIF OUT channel and the sender sends the receipt acknowledgment to the receiver.

Consider two partners, wood supplier (enterprise-sender) and paper supplier (receiver).

The following image illustrates the two-way PIP document exchange:

Before You Begin

You need the following design-time assets at the sender’s side:

You need the following design-time assets at the receiver’s side:

On the Sender’s (wood supplier) side

  1. PIP_3A4_PO_Request document is submitted from webMethods.io Integration to webMethods.io B2B (Enterprise wood supplier).
  2. The enterprise sender, wood supplier, sends this document over an RNIF Outbound channel using a custom processing rule Devlier3A4ToPaperSupplier..

    The RNIF PIP 3A4 PO request (PIP_3A4_v02_00_Request) is sent to paper supplier.

  3. Wood supplier receives receipt acknowledgment from paper supplier.

At the Receiver’s (paper supplier) End

  1. The receiver paper supplier receives a PIP 3A4 PO request (PIP_3A4_v02_00_Request) from wood supplier over asynchronous RNIF IN channel and generates and sends A_PIP_3A4_PO_Confirmation using a custom processing rule Generate3A4POConfirmationToWoodSupplier and Send3A4POConfirmationToWoodSupplier.

  2. Paper supplier receives the receipt acknowledgment from wood supplier.

The RNIF payload is exchanged using two-way PIP document exchange.