EDIINT MDN Building Service

How the EDIINT MDN Building Service Works

The following steps summarize how the EDIINT MDN Building service works within a business process:

1. The EDIINT MDN Building service is used to build an MDN based on information in process data and a specified contract ID.
2. The EDIINT MDN Building service uses the production profile in the specified contract ID as the originator information and the consumption profile in the specified contract ID as the recipient information.

Implementing the EDIINT MDN Building Service

To implement the EDIINT MDN Building service, complete the following tasks:

1. Activate your license for the EDIINT MDN Building service.
2. Create an EDIINT MDN Building service configuration.
3. Configure the EDIINT MDN Building service only once in the User Interface and the GPM. You can also modify the EDIINTMDNBuild predefined service instance.
4. Use the EDIINT MDN Building service in a business process.

Configuring the EDIINT MDN Building Service

To configure the EDIINT MDN Building service, you must specify settings for the following fields in the IBM Sterling B2B Integrator one time only.

Parameters Passed from the Business Process to the Service

Use the field definitions in the following table to set up the business process correctly:

Parameter

Description

b2b-contract-id

The ID of a contract containing information for building messages. Must be the ID of an existing contract.

Note: This parameter must either be specified in the GPM or in the service configuration user interface. Please see Use of Contract ID for more information.

EDIINT-MDN-Protocol

The signature format requested for the MDN from the Disposition-Notification-Options header of the message from the EDIINT Message service (or EDIINT Pipeline service). The only acceptable value for this field is pkcs7-signature.

EDIINT-Receipt-Delivery-
Protocol

The actual transport protocol that the EDIINT Message service (or EDIINT Pipeline service) determined that the MDN must use. The standard value for this field is http.

EDIINT-MIC-Alg

The MIC algorithm requested for the MDN from the Disposition-Notification-Options header of the message from the EDIINT Message service (or EDIINT Pipeline service).

Note: You should not alter this value unless you plan to supply a received-content-MIC with the supplied algorithm.

EDIINT-Received-Content-MIC

The received-content-MIC that is computed by the EDIINT Message service (or the EDIINT Pipeline service) when processing the message.

Note: You can alter or add this value if you have a received-content-MIC from another source than the EDIINT Message service or EDIINT Pipeline service or if one of those services has been customized by services so that it does not produce a received-content-MIC.

EDIINT-MDN-Recipient

The receiver of the MDN message from the EDIINT Message service (or EDIINT Pipeline service).

Note: The EDIINT MDN Building service uses the consumption profile in the specified contract ID as the recipient information.

EDIINT-MDN-Sender

The sender of the MDN message from the EDIINT Message service (or EDIINT Pipeline service).

Note: The EDIINT MDN Building service uses the production profile in the specified contract ID as the originator (sender) information.

EDIINT-MDN-Disposition

The disposition of the MDN from the EDIINT Message service (or EDIINT Pipeline service).

Note: Generally this should be the string processed, although there are some situations noted in the AS2 specification in which you could set this parameter to failure. It is recommended that you do not change this parameter without careful thought.

EDIINT-MDN-Disposition-Modifier

The disposition modifier of the MDN from the EDIINT Message service (or EDIINT Pipeline service). This is only present if message parsing failed. Valid values are:

• Error: authentication-failed
• Error: decryption-failed
• Error: decompression-failed
• Error:unexpected-processing-error

Note: There are other modifiers permitted by the AS2 specification, but the valid values are the only ones supported by the IBM Sterling B2B Integrator. If a message is processed without errors by the EDIINT Message service, the EDIINT-MDN-Disposition is processed and there is no EDIINT-MDN-Disposition-Modifier. In this situation, you can add the disposition modifier Error: unexpected-processing-error in the event that the safe-store operation fails by using an assign like the following:

<assign to="EDIINT-MDN-Disposition-Modifier">Error:
unexpected-processing-error</assign>

EDIINT-MDN-Original-
Message-Document-ID

The document identifier of the message the EDIINT Message service (or EDIINT Pipeline service) processed.

EDIINT-MDN-Transaction-Type

The transaction type as determined by the EDIINT Message service (or EDIINT Pipeline service). Valid values are AS1 or AS2.

EDIINT-Receipt-Delivery-
Port

The port on which that the EDIINT Message service (or EDIINT Pipeline service) determined the MDN would be sent.

Use-Contract-In-Reverse

This parameter must be set to True if you need to use the same contract the EDIINT Message service or EDIINT Pipeline service uses to parse a message.

Business Process Example

This example uses an instance of the EDIINT MDN Building Service named EDIINTMDNBuild. The default EDIINT parsing business process (EDIINTParse) was altered to replace the single step that calls the EDIINT Message Service for parsing the message with the following BPML containing three steps to build and then synchronously send the MDN later. If you are sending the MDN asynchronously or are unsure whether you would send the MDN synchronously and asynchronously, you will have to invoke a different sending process (for example, HTTPAsyncSend) or add logic for making the synchronous or asynchronous decision and invoking the appropriate process.

<operation name="One">
    <participant name="EDIINTPipelineParse"/>
      <output message="noopout">
       <assign to="." from="*"></assign>
       <assign to="ShowTranscripts">true</assign> 
       <assign to="DontBuildMDN">true</assign> 
      </output>
      <input message="noopin">
       <assign to="." from="*"></assign>
      </input>
  </operation>
 
  <operation name="Two">
    <participant name="EDIINTMDNBuild"/>
      <output message="noopout">
       <assign to="." from="*"></assign>
       <assign to="ShowTranscripts">true</assign> 
      </output>
      <input message="noopin">
       <assign to="." from="*"></assign>
      </input>
  </operation>
 
  <operation name="InvokeSendBP">
   <participant name="InvokeBusinessProcessService" />
    <output message="Xout">
     <assign to="INVOKE_MODE">INLINE</assign>
     <assign to="NOTIFY_PARENT_ON_ERROR">ALL</assign>
     <assign to="WFD_NAME">HTTPSyncSend</assign>
     <assign to="." from="*"></assign>
    </output>
    <input message="Xin" >
     <assign to="." from="*"></assign>
    </input>
   </operation>

External System Interaction

An external system is responsible for originating the AS2 message that the MDN is acknowledging. Many external systems employ an MDN timeout feature to determine whether an AS2 message was successfully sent. If the MDN is not received within a certain amount of time, the send is assumed to have failed. The length of this timeout is not standard; it is set by the external system. The external system also decides the actions that are taken if the MDN is not received in the specified length of time. For example, the external system might resend the message or perform some sort of manual intervention. The IBM Sterling B2B Integrator has no control over any actions taken by the external system.

Use of Contract ID

You can specify a contract ID when you create an EDIINT MDN Building service instance, but it is not necessary. When the EDIINT Message Service parses a message, it typically looks up a contract and the contract ID is assigned to the BPML parameter b2b-contract-id. The EDIINT MDN Building service configuration can use the same contract ID (you set this in the b2b-contract-id parameter). However, you do need to set the Use-Contract-In-Reverse parameter to reuse the same contract.

You only need to explicitly assign one contract ID unless you need to use a different contract ID from the contract ID previously defined or you are using the EDIINT Message Service or EDIINT Pipeline service in a manner in which the contract ID is not specified.