Reference Information

Reference Information For Asset Movement

Skipped Assets

The main asset types that are not supported in the cloud instance for asset migration are Skipped and they are as follows:

Ignored Properties in Moved Assets

Certain properties of the assets that are imported are ignored during the movements, and those are listed under Ignored category.

Asset Type Ignored
Partner profiles
  • Delivery settings
  • Preferred Protocol
  • Preferred Language (Locale)
  • Polling Method (Delivery Settings)
  • Polling Frequency (Delivery Settings)
  • Remote Status
  • Sub Status
  • Company Logo
  • References to partner groups
Queues
  • Queues with any delivery service except EDI batch.
  • Queues with scheduler combination as:
    • Yearly
    • Days of month and week together
    • Multiple hours and minutes
Business documents
  • Attribute transformation of extracted attributes with custom service.
  • The document type reference for XML document type.
  • Flat file document types
  • EDI document types
  • The reference for:
    • Format as an IS document Type
    • Validate Structure
    • Duplicate Document Check
Processing rules
  • The reference for:
    • Duplicate Check Service
    • Validate Structure
    • Verify Digital Signature
    • Change User Status Action
    • Service Execution
    • Respond With
    • Queue for Polling
    • Immediate Delivery
Extended fields
  • The extended field related to the system field group.
  • The extended field related to the field definition of type other than string.
Trading partner agreements
  • Initialization Service (initService)
  • Export Service
  • Validation Service
  • Control Number

System-Generated Assets

The system-generated assets are not moved from one instance to another.

The following table lists all the system-generated assets for each asset type:

Asset Type Sub-category System generated properties for each asset type
Document attributes RNIF document attributes
  • RNIF InReplyTo MessageTracking ID
  • RNIF MessageTracking ID
  • RNIF PIPInstance ID
  • Ignore PRT Document
IBM webMethods B2B system doc attributes
  • NS Name
  • ConversationID
  • DocumentID
  • GroupID
  • ReceiverID
  • SenderID
  • Signature
  • Signed Body
  • UserStatus
EDI system doc attributes
  • ApplicationReference
  • BatchRecipientsReference
  • Data ContentType
  • Deliver FA
  • EDI FA Status
  • EDI Transport Media
  • EDI Acknowledgment
  • EDI Batch
  • EDI FA Control Number
  • EDI Group Type
  • EDIINT Delivery URI
  • EDIINT ETag
  • EDIINT MDN Disposition
  • EDIINT MDN Orig Msg ID
  • EDIINT MDN Received MIC
  • EDIINT Message Digest
  • EDIINT Message doPayload
  • EDIINT Message ID
  • EDIINT Message Type
  • EDIINT Receiver ID
  • EDIINT Sender ID
  • EDIINT User Payload Processed
  • Late FA
  • EDI Outbound FA
  • EDI Processing Mode
  • EDI Standard
  • EDI Status
  • EDI Transaction Count
  • EDI Version
  • Envelope CtrlNum Status
  • Group CtrlNum Status
  • Has RSGRSG
  • Is Multiple Envelope
  • MessageVersion
  • ReceiversTransmissionReference
  • Syntax Identifier
  • Syntax Release Number
  • SyntaxRulesIdentifier
  • TA1 Code
  • TA1 Status
  • Transaction CtrlNum Status
  • Directory Version Number
  • EDIINT Payload Dir
  • PriorityCode
Document Types RNIF document types
  • Exception (RNIF 2.0)
  • ReceiptAcknowledgment (RNIF 2.0)
  • RN20BizDocType
  • RosettaNet Dummy DocType
IBM webMethods B2B document types
  • Unknown
  • Record Document
  • PROFVAL_stdFields
  • PROFVAL_Profile
  • PROFVAL_extFields
EDI document types
  • EDIINT MDN
  • EDIINT
  • EANCOM Envelope
  • EANCOM Group
  • EDI Batch Envelope
  • EDI Batch Group
  • ODETTE Envelope
  • ODETTE Group
  • TRADACOMS Batch
  • TRADACOMS Transmission
  • TRADACOMS 9 INVFIL
  • UCS Envelope
  • UCS Group
  • UNEDIFACT Envelope
  • UNEDIFACT Group
  • VDA Envelope
  • VICS Envelope
  • VICS Group
  • X12 Envelope
  • X12 Group
  • X12 TA1
Field Groups IBM webMethods B2B system field groups
  • Corporation
  • Contact
  • Delivery
  • Custom
  • External ID
  • Address
EDIINT system field groups EDIINT
Processing rules On-premise processing rules
  • EDIINT Send Message
  • EDIINT Process Message - Persist Payload in File system
IBM webMethods B2B processing rules
  • Deliver Functional Acknowledgment
  • EDIINT Process MDN Message
  • EDIINT Process Message
  • Profile Validation Standard Fields
  • Profile Validation Profile
  • Profile Validation Extended Fields
  • Default rule
  • EDIINT Send MDN Message Using Channel
  • EDIINT Send Message Using Channel
Trading partner agreements Trading partner agreements definition
  • RNIFTPA
  • EDITPA
Trading partner agreements template
  • AS4V1
  • EDIV1
  • RNIFV1

Working with EDI TPA Parameters

EDITPA Variable Description
GSRouting Variables IBM webMethods B2B creates Interchange, Group, and Transaction documents based on the splitOption variable in the EDITPA
PersistMultipleDocEnvelope Variable The persistMultipleDocEnvelope variable indicates whether IBM webMethods B2B saves the original document in the IBM webMethods B2B database.
processingMode Variable The processingMode variable indicates whether the partners using the EDITPA are in testing, production, or custom mode.
splitOption Variable The splitOption variable defines how IBM webMethods B2B splits an interchange segment within an EDI document.
FAReconciliation Variable) The FAReconciliation variable indicates whether to enable FA reconciliation.
UNAmode Variable The UNAmode variable indicates whether you want to create a UNA segment to precede the interchange in an outbound UN/EDIFACT EDI document.
delimiters Variables The delimiters/record variable indicates the segment terminator to use in an outbound EDI document.
envelopeIdentifier Variables The envelopeIdentifier variables consist of ID and qualifier variables for senders and receivers.
ICheaderInfo Variables The ICheaderInfo variables indicate the values to use for ANSI X12 interchange and group headers and UN/EDIFACT UNB headers in outbound EDI documents.
FAGeneration Variables The FAGeneration/autoGenerateFA variable indicates whether you want IBM webMethods B2B to automatically generate FAs for an inbound EDI document.
Control Number Management The control number variables indicate whether you want to validate and track control numbers in the interchange headers of inbound EDI documents.
BatchCriteria Variables Grouping together transactions from all queued EDI documents.
persistOriginalEnvelope Variable The persistOriginalEnvelope variable indicates whether to persist the original incoming EDI envelope in IBM webMethods B2B before IBM webMethods B2B starts processing the EDI envelope.
documentPersistOrder Variable The documentPersistOrder variable indicates the order in which the EDI documents are submitted to IBM webMethods B2B.

GSRouting Variables

IBM webMethods B2B creates Interchange, Group, and Transaction documents based on the splitOption variable in the EDITPA. The GSRouting variables indicate the value for the sender and receiver in these documents.

The values that you select for the GSRouting variables determine:

GSRouting/routingMode

Default: OFF

The routingMode variable indicates how IBM webMethods B2B obtains the sender and receiver for each type of document. The following table provides the possible values for this variable. The examples use the following headers:

ISA*00**00**01*123456789*ZZ*987654321*020201*1535*U*00300*000004323*0*P

GS*PO*901234572000*908887732000*020201*1535*4369*X*003020
Value Description
GSOnly IBM webMethods B2B determines the sender and receiver as follows:
For Interchange documents, IBM webMethods B2B uses the interchange header. For example, the sender uses EDI ID qualifier 01 with value 123456789 and the receiver uses the EDI ID qualifier ZZ with the value 987654321.
For Group and Transaction documents, IBM webMethods B2B uses the group header. For example, the sender uses the value 901234572000 and the receiver uses the value 90888773200. For the EDI ID qualifiers, see the GSRouting/senderQualifier and GSRouting/receiverQualifier variables.
GS&ISA IBM webMethods B2B determines the sender and receiver described in the following sample payload:

ISA*00* *00**01*123456789 *ZZ*987654321 *020226*1534*U*00401*000000009*0*T*>~ GS*PO*901234572000*908887732000*20020226*1534*1*X*003041~

For Interchange documents, IBM webMethods B2B uses the interchange header.
For example, the sender uses EDI ID qualifier 01 with value 123456789 and the receiver uses the EDI ID qualifier ZZ with the value 987654321.
Make sure your Interchange segment contains ZZ in uppercase.
For Group and Transaction documents, IBM webMethods B2B derives the sender by concatenating ISA05, ISA06, and GS02 fields, using a colon (:) separator. And derives the receiver ID by concatenating ISA07, ISA08, and GS03.
For example, the sender is identified as 01:123456789:901234572000 and the receiver is identified as ZZ:987654321:908887732000. The EDI ID qualifiers are always ZZ (Mutually Defined) when you use GS&ISA. Make sure you add these concatenated values as the external identifiers in the corresponding partner profiles with the ID type set as Mutually Defined(ZZ).
OFF IBM webMethods B2B determines the sender and receiver as follows: For Interchange, Group, and Transaction documents, IBM webMethods B2B uses the interchange header. For example, the sender uses the EDI ID qualifier 01 with the value 123456789 and the receiver uses the EDI ID qualifier ZZ with the value 987654321.

GSRouting/senderQualifier
Default: *

The senderQualifier variable indicates the EDI ID qualifier that IBM webMethods B2B uses for the sender when the GSRouting/routingMode variable is GSOnly.

Value Description
* IBM webMethods B2B uses the EDI ID qualifier for the sender from the interchange header (for example, ISA05 field).
Other EDI ID qualifiers You can specify any EDI ID qualifier that the EDI standard supports. For all EDI ID qualifiers, see the documentation for your EDI standard and version.
Note
Be sure to add the external ID types to IBM webMethods B2B for the EDI ID qualifier you specify, if necessary.

GSRouting/receiverQualifier
Default: *
The receiverQualifier variable indicates the EDI ID qualifier that IBM webMethods B2B uses for the receiver when the GSRouting/routingMode variable is GSOnly.

Value Description
* IBM webMethods B2B uses the EDI ID qualifier for the receiver from the interchange header (for example, ISA07 field).
Other EDI ID qualifiers You can specify any EDI ID qualifier that the EDI standard supports. For all EDI ID qualifiers, see the EDI Standards documentation for your EDI standard and version.
Note
Be sure to add the external ID types to IBM webMethods B2B for the EDI ID qualifier you specify, if necessary.

PersistMultipleDocEnvelope Variable

persistMultipleDocEnvelope

Default: true

The persistMultipleDocEnvelope variable indicates whether IBM webMethods B2B saves the original document in the IBM webMethods B2B database. The original EDI document usually contains multiple interchange segments. IBM webMethods B2B only uses the persistMultipleDocEnvelope variable from the default EDITPA.

Note
IBM webMethods B2B splits each interchange segment within the original EDI document into Interchange, Group, and Transaction documents based on the setting of the splitOption EDITPA variable. Control whether the Interchange, Group, and Transaction documents are saved in the IBM webMethods B2B database in the processing rule.
Value Description
true IBM webMethods B2B saves the original EDI document in the database. The document is saved with both the sender and receiver set to unknown.
false IBM webMethods B2B does not save the original EDI document in the database. When you specify false, there is no way to retrieve the original EDI document later.

processingMode Variable

processingMode

Default: Testing

The processingMode variable indicates whether the partners using the EDITPA are in testing, production, or custom mode. When processing Interchange, Group, and Transaction documents, IBM webMethods B2B includes the document attribute EDI Processing Mode and sets the value of this attribute based on the processingMode EDITPA variable.

In your processing rules for Interchange, Group, and Transaction documents, you can use the EDI Processing Mode document attribute to customize processing according to the partner’s processing mode. For example, you might set up two processing rules: one for when partners are in testing mode and another for when partners are in production mode.

Value Description
Testing Use when testing the exchange of documents between two partners. For example, when the production mode is Testing, you might create processing rules that accept the documents and do all processing except passing the document to production applications.
Production Use when you are confident that your logic for exchanging documents is successful.
Custom Use when you want to define your own setting.
Interchange Define IBM webMethods B2B sets the value of EDI Processing Mode document attribute based on the processing mode defined in the interchange header.
For an ANSI X12 document, IBM webMethods B2B defines the processing mode based on the value of ISA015, as follows:
- T or others. Sets the EDI processing mode document attribute to Testing.
- P. Sets the processing mode document attribute to Production.
- I. Sets the processing mode document attribute to Custom.
For a UN/EDIFACT document, IBM webMethods B2B defines the processing mode attribute based on the value of UNB11, as follows:
1,2,3,4 or others. Sets the processing mode attribute to Testing
Empty. Sets the processing mode attribute to Production

splitOption Variable

splitOption

Default: Transaction

The splitOption variable defines how IBM webMethods B2B splits an interchange segment within an EDI document. The splitOption determines which of the following document types to create from the interchange segment:

To perform processing on the transactions in an inbound document, set splitOption to Transaction or Group. To route the inbound EDI document without processing individual transactions, set the splitOption to Interchange.

The following table lists the possible values for the splitOption variable and the types of documents that IBM webMethods B2B creates for each value.

Field Value
Interchange IBM webMethods B2B creates only the Interchange document.
Note
When splitOption is Interchange and the FAReconciliation EDITPA variable is set to true, IBM webMethods B2B splits the document at the Group level.
Group IBM webMethods B2B creates the Interchange document and a Group document for each group segment in the interchange segment.
Transaction IBM webMethods B2B creates the Interchange document, a Group document for each group segment in the interchange segment, and a Transaction document for each transaction set in the interchange segment.

FAReconciliation Variable

FAReconciliation

Default: false

The FAReconciliation variable indicates whether to enable FA reconciliation so IBM webMethods B2B performs both of the following:

To reconcile FAs, IBM webMethods B2B makes a record of each Group/Interchange EDI document that it sends and receives. For ANSI EDI documents, IBM webMethods B2B records each Group document it sends or receives. For UN/EDIFACT EDI documents, IBM webMethods B2B records each Group document if the EDI document contains Group-level documents; if it does not, IBM webMethods B2B records Interchange-level document. IBM webMethods B2B records the information about these documents to the EDITRACKING table, which is table pertaining to EDI parameters in the database.

Note
When you form an outbound EDI document and send it directly to the processing rules rather than allow IBM webMethods B2B to recognize the document with its document types, you need to invoke the wm.b2b.editn:trackEDIdocs service to record the outbound document in the EDITRACKING table.

When FA reconciliation is enabled, IBM webMethods B2B updates the status for each Group/Interchange document in the EDITRACKING table when it sends or receives the Group/Interchange document’s corresponding FA.

Value Description
true IBM webMethods B2B enables FA reconciliation.
  • When IBM webMethods B2B sends or receives a Group/Interchange document, it adds an entry to the EDITRACKING table the document and sets the FA status to None.
  • When IBM webMethods B2B receives or sends the corresponding FA, it attempts to locate the corresponding Group/Interchange document in the EDITRACKING table.
  • When IBM webMethods B2B locates a matching entry, it updates the FA status. For example, if IBM webMethods B2B locates one matching document and the FA has the “A” (Accept) status, IBM webMethods B2B updates the FA status to Accept.
  • When IBM webMethods B2B cannot find a matching entry, it adds an entry for the FA to the EDITRACKING table.
    		•
    false IBM webMethods B2B disables FA reconciliation.
  • When IBM webMethods B2B sends or receives a Group or Interchange document, it adds an entry to the EDITRACKING table the document and sets the FA status to Disable.
  • When IBM webMethods B2B receives or sends the corresponding FA, it attempts to locate the corresponding Group/Interchange document in the EDITRACKING table.
  • When IBM webMethods B2B locates a matching entry and the status is Disable. Does nothing.
  • When IBM webMethods B2B locates a matching entry and the status is None. Updates the status to Disable.
  • When IBM webMethods B2B cannot find a matching entry, it adds an entry for the FA to the EDITRACKING table.
    		•

    UNAmode Variable

    UNAmode

    Default: auto

    The UNAmode variable indicates whether you want to create a UNA segment to precede the interchange in an outbound UN/EDIFACT EDI document.

    When you use the IBM webMethods B2B batching feature to create an outbound EDI document, the batchProcess service honors this setting.

    Additionally, integrations you create to form outbound UN/EDIFACT EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    Value Description
    yes IBM webMethods B2B creates the UNA segment prior to the interchange in the outbound EDI UN/EDIFACT document.
    no IBM webMethods B2B does not create UNA segment prior to the interchange in the outbound EDI UN/EDIFACT document.
    auto IBM webMethods B2B creates the UNA segment prior to the interchange in the outbound EDI UN/EDIFACT document.

    delimiters Variables

    delimiters/record

    Default: (no default)

    The delimiters/record variable indicates the segment terminator to use in an outbound EDI document, for example, +. Integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When you use the batching feature to create an outbound EDI document, if you do not specify the delimiters input parameter to the batchProcess service, the batchProcess service retrieves this setting from the EDITPA.

    delimiters/field

    The delimiters/field variable indicates the field separator to use for each EDI segment in an outbound EDI document, for example, !. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When you use the batching feature to create an outbound EDI document, if you do not specify the delimiters input parameter to the batchProcess service, the batchProcess service retrieves this setting from the EDITPA.

    delimiters/subfield

    Default: (no default)

    The delimiters/subfield variable indicates the separator to use for composite elements in an outbound EDI document, for example, *. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When you use the batching feature to create an outbound EDI document, if you do not specify the delimiters input parameter to the batchProcess service, the batchProcess service retrieves this setting from the EDITPA.

    delimiters/release

    Default: (no default)

    The delimiters/release variable indicates the release character to use for an outbound EDI document (for example, “\\xd3). The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When you use the batching feature to create an outbound EDI document, if you do not specify the delimiters input parameter to the batchProcess service, the batchProcess service retrieves this setting from the EDITPA.

    envelopeIdentifier Variables

    The envelopeIdentifier variables consist of ID and qualifier variables for senders and receivers.

    envelopeIdentifier/sender/ID

    Default: (no default)

    The envelopeIdentifier/sender/ID variable indicates the sender ID to use for an outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature:

  • When the batchProcess service oneBatchQueue input parameter is NONE, the batchProcess service uses its input parameters to locate the EDITPA, and then uses the envelopeIdentifier variables to set the sender/receiver in the interchange and group headers of the outbound batch EDI document.
  • When you are using batching with oneBatchQueue set to SINGLEOUTPUT or MULTIPLEOUTPUTS, do not specify the envelopeIdentifier/sender/ID variable.

    • envelopeIdentifier/sender/qualifier

    Default: (no default)

    The envelopeIdentifier/sender/qualifier variable indicates the EDI ID qualifier associated with the value you specify for envelopeIdentifier/sender/ID. For example, if you specified a D-U-N-S number for the envelopeIdentifier/sender/ID, for envelopeIdentifier/sender/qualifier specify 01, which is the EDI ID qualifier for a D-U-N-S number. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature:

  • When the batchProcess service oneBatchQueue input parameter is NONE, the batchProcess service uses its input parameters to locate the EDITPA, and then uses the envelopeIdentifier variables to set the sender/receiver in the interchange and group headers of the outbound batch EDI document.
  • When you are using batching with oneBatchQueue set to SINGLEOUTPUT or MULTIPLEOUTPUTS, do not specify the envelopeIdentifier/sender/ID variable.

    • envelopeIdentifier/receiver/ID

    Default: (no default)

    The envelopeIdentifier/receiver/ID variable indicates the receiver ID to use for an outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature:

  • When the batchProcess service oneBatchQueue input parameter is NONE, the batchProcess service uses its input parameters to locate the EDITPA, and then uses the envelopeIdentifier variables to set the sender/receiver in the interchange and group headers of the outbound batch EDI document.
  • When you are using batching with oneBatchQueue set to SINGLEOUTPUT or MULTIPLEOUTPUTS, do not specify the envelopeIdentifier/sender/ID variable.

    • envelopeIdentifier/receiver/qualifier

    Default: (no default)

    The envelopeIdentifier/receiver/qualifier variable indicates the EDI ID qualifier associated with the value you specify for envelopeIdentifier/receiver/ID. For example, if you specified a D-U-N-S number for the envelopeIdentifier/receiver/ID, specify 01 for envelopeIdentifier/receiver/qualifier, which is the EDI ID qualifier for a D-U-N-S number. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature:

  • When the batchProcess service oneBatchQueue input parameter is NONE, the batchProcess service uses its input parameters to locate the EDITPA, and then uses the envelopeIdentifier variables to set the sender/receiver in the interchange and group headers of the outbound batch EDI document.
  • When you are using batching with oneBatchQueue set to SINGLEOUTPUT or MULTIPLEOUTPUTS, do not specify the envelopeIdentifier/sender/ID variable.

    • ICheaderInfo Variables

    The ICheaderInfo variables indicate the values to use for ANSI X12 interchange and group headers and UN/EDIFACT UNB headers in outbound EDI documents.

    ICheaderInfo/ISA/ISA01

    Default: 00

    The ICheaderInfo/ISA/ISA01 variable indicates the value to use for the ISA01 element of an ANSI X12 interchange header in an outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature, IBM webMethods B2B uses this setting when creating the interchange headers of the outbound batch EDI document.

    ICheaderInfo/ISA/ISA02

    Default: (no default)

    The ICheaderInfo/ISA/ISA02 variable indicates the value to use for the ISA02 element of an ANSI X12 interchange header in an outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature, IBM webMethods B2B uses this setting when creating the interchange headers of the outbound batch EDI document.

    ICheaderInfo/ISA/ISA03

    Default: (no default)

    The ICheaderInfo/ISA/ISA04 variable indicates the value to use for the ISA04 element of an ANSI X12 interchange header in an outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature, IBM webMethods B2B uses this setting when creating the interchange headers of the outbound batch EDI document.

    ICheaderInfo/ISA/ISA11

    Default: U

    The ICheaderInfo/ISA/ISA11 variable indicates the value to use for the ISA11 element of an ANSI X12 interchange header in an outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature, IBM webMethods B2B uses this setting when creating the interchange headers of the outbound batch EDI document.

    ICheaderInfo/GS/GS07

    Default: (no default)

    The ICheaderInfo/GS/GS07 variable indicates the value to use for the GS07 element of an ANSI X12 group header in an outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature, IBM webMethods B2B uses this setting when creating the interchange headers of the outbound batch EDI document.

    ICheaderInfo/UNB/UNB01

    Default: (no default)

    The ICheaderInfo/UNB/UNB01 variable indicates the value to use for the UNB01 element of a UN/EDIFACT UNB header in the outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature, IBM webMethods B2B uses this setting when creating the interchange headers of the outbound batch EDI document.

    ICheaderInfo/UNB/UNB06

    Default: (no default)

    The ICheaderInfo/UNB/UNB06 variable indicates the value to use for the UNB06 element of a UN/EDIFACT UNB header in the outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using the batching feature, IBM webMethods B2B uses this setting when creating the interchange headers of the outbound batch EDI document.

    ICheaderInfo/UNB/UNB08

    Default: (no default)

    The ICheaderInfo/UNB/UNB08 variable indicates the value to use for the UNB08 element of a UN/EDIFACT UNB header in the outbound EDI document. The integrations you create to form outbound EDI documents can retrieve this setting from the EDITPA using the getTPA operation on IBM webMethods Integration.

    When using batching feature, IBM webMethods B2B uses this setting when creating the interchange headers of the outbound batch EDI document.

    FAGeneration Variables

    FAGeneration/autoGenerateFA

    Default: Off

    The FAGeneration/autoGenerateFA variable indicates whether you want IBM webMethods B2B to automatically generate FAs for an inbound EDI document.

    Value Description
    On Always automatically generates FAs for inbound EDI documents
    Off Never automatically generates FAs for inbound EDI documents
    Per Document Automatically generates FAs based on the indicator flag in the interchange header (for example, ISA14 or UNB09).

    FAGeneration/FALevel

    Default: Default

    The FAGeneration/FALevel variable defines the level of detail that the IBM webMethods B2B acknowledges in the FAs that it generates.

    Value Description
    Default Acknowledges at the envelope level (group for ANSI X12 documents and interchange for UN/EDIFACT documents).
    TransactionSet Acknowledges at the transaction set level.
    Segment Acknowledges at the segment level.
    Element Acknowledges at the element level.
    Note
    When you are generating FAs at the element level, be sure to configure the maximum number of errors to report per FA transaction.

    FAGeneration/processDocument

    Default: All

    The FAGeneration/processDocument variable indicates how you want IBM webMethods B2B to process a transaction, group, or UN/EDIFACT interchange based on its FA status.
    Use this EDITPA variable to define which FA statuses are acceptable and which are unacceptable.

  • For acceptable FA statuses, IBM webMethods B2B processes a transaction, group, or UN/EDIFACT interchange using its normal processing.

  • For unacceptable FA statuses, IBM webMethods B2B processes documents differently.

    • The following table describes the settings for the FAGeneration/processDocument EDITPA variable, when to use each one, and the acceptable and unacceptable FA statuses based on the processDocument setting.

    Set process Document to When you want to Acceptable FA statuses Unacceptable FA statuses
    All Process all Interchange, Group, and Transaction documents regardless of their FA status. All None
    Only Accepted Process only Interchange, Group, and Transaction documents that have the FA status “Accepted”. Accepted
  • Not Allowed

  • Rejected

  • Partially Accepted
  • Accepted, But Errors Were Noted
    		•
    Not Rejected Process all Interchange, Group, and Transaction documents unless they have the FA status “Rejected”.
  • Not Allowed

  • Partially Accepted

  • Accepted, But Errors Were Noted

  • Accepted
    		•  Rejected

    FAGeneration/generateControlNumber

    Default: FromInboundDocument

    The FAGeneration/generateControlNumber variable defines how IBM webMethods B2B is to generate the control numbers that it uses in the interchange and group headers of the FAs that it automatically generates.

    Value Description
    FromInboundDocument IBM webMethods B2B uses the control numbers from the corresponding headers of the inbound EDI document that the FA acknowledges. For example, if acknowledging a group, IBM webMethods B2B uses the control number from the corresponding group header in the inbound document.
    Random IBM webMethods B2B randomly generates control numbers for the interchange and group headers of the FA.
    FromControlNumberTable IBM webMethods B2B obtains the control numbers from the database. IBM webMethods B2B searches the database for the entry that matches the sender/receiver, EDI standard/version, production mode, and type (for example, Envelope or group type) identified in the corresponding interchange or group header of the inbound EDI document that the FA acknowledges. IBM webMethods B2B uses the next control number from this EDIControlNumber table entry for the FA. It also increments the value of the next control number in the table entry, so it reflects the new next control number.
    Note
    IBM webMethods B2B always sets the control number for the transaction (997 or CONTRL) to 001.

    FAGeneration/addGroup

    Default: false

    The FAGeneration/addGroup variable indicates whether you want IBM webMethods B2B to add a functional group to the UN/EDIFACT FA (for example, CONTRL).

    Value Description
    true Adds a functional group to the FA.
    false Does not add a functional group to the FA. This is the default.

    FAGeneration/ctlNumberWleadingZero

    Default: false

    The FAGeneration/ctlNumberWleadingZero variable indicates whether you want IBM webMethods B2B to fill the control number field value with leading zeros. For example, if the control number is 34, and the length of the field is eight, and if the FAGeneration/ctlNumberWleadingZero variable is set to true, IBM webMethods B2B sets the control number field value to 00000034.

    Value Description
    true Adds leading zeros to the control number field value.
    false Does not add zeros to the control number field value.

    FAGeneration/RejectionRules/syntaxErrorStatus

    Default: Rejected

    The FAGeneration/RejectionRules/syntaxErrorStatus variable indicates how you want IBM webMethods B2B to report the syntax error status for a transaction, group, or UN/EDIFACT interchange.

    Value Description
    Rejected Use this setting when you want to reject the element (for example, transaction) because of syntax errors. Reports the syntax error status as:
    Accepted. When there are no syntax errorsRejected.
    When there are syntax errors
    Accepted, But Errors Were Noted Use this setting when you want to know whether there were syntax errors, but you do not want to reject the element (for example, transaction) because of syntax errors. Reports the syntax error status as:
  • Accepted. When there are no syntax errors.
  • Accepted, But Errors Were Noted. When there are syntax errors
    		•
    Accepted Use this setting when you do not want to check for syntax errors. Always reports the syntax error status as Accepted regardless of whether there are any syntax errors.

    FAGeneration/RejectionRules/logicalErrorStatus

    Default: Rejected

    The FAGeneration/RejectionRules/logicalErrorStatus variable indicates how you want IBM webMethods B2B to report the logical error status.

    Value Description
    Rejected Reports the logical error status as:
  • Accepted. When there are no logical errors.
  • Rejected. when there are logical errors.

    • Use this setting when you want to reject the element (for example, transaction) because of logical errors.
    Accepted, But Errors Were Noted Reports the logical error status as:
  • Accepted. When there are no logical errors.

  • Accepted, But Errors Were Noted. When there are logical errors.

    • Use this setting when you want to know whether there were logical errors but do not want to reject the element (for example, transaction) because of logical errors.
    Accepted Always reports the logical error status as Accepted regardless of whether there are any logical errors. Use this setting when you do not want to check for logical errors.

    FAGeneration/RejectionRules/childTransactionRejectedStatus

    Default: Rejected

    The FAGeneration/rejectionRules/childTransactionRejectedStatus variable indicates how you want IBM webMethods B2B to report the child transaction rejected status. The child transaction rejected status indicates whether child elements of a group or UN/EDIFACT interchange have an FA status of Rejected.

    Value Description
    Rejected Reports the child transaction rejected status as:
  • Rejected. When the FA status of any of the child transactions is either Rejected or Accepted, But Errors Were Noted.
  • Accepted. When the FA statuses of all the child transactions are Accepted.
    Use this setting when the FA status of all of the child transactions are Rejected.
    		•
    Partially Accepted Reports the child transaction rejected status as:
  • Rejected. When the FA statuses of all of the child transactions are “Rejected”.

  • Partially Accepted. When the FA status of at least one child transaction is Accepted, but the FA status of other child transactions are Rejected and/or Accepted, But Errors Were Noted.

  • Accepted, But Errors Were Noted. When the FA statuses of the child transactions are either Rejected and/or Accepted, But Errors Were Noted AND no child transactions are Accepted.

  • Accepted. When the FA statuses of all the child transactions are Accepted.

    • Use this setting when the FA status of at least one child transaction is Accepted and one is Rejected.
    Accepted, But Errors Were Noted Reports the child transaction rejected status as:
  • Rejected. when all the child transactions areRejected.

  • Accepted, But Errors Were Noted. When the FA statuses of the child transactions are Rejected, Accepted, But Errors Were Noted, and Accepted.

  • Accepted. When the FA statuses of all the child transactions are Accepted.Use this setting when the FA status of at least one child transaction is Accepted, But Errors Were Noted.
    		•

    FAGeneration/deliverFA

    Default: true

    Indicates whether the FA document needs to be auto delivered to the partner or not.

    Value Description
    true Delivers the functional acknowledgment to the partner.
    false Does not deliver the functional acknowledgment to the partner.

    FAGeneration/splitFAOption

    Default: Interchange

    Indicates whether to generate the FA document for interchange, group, and transaction.

    Value Description
    Interchange Splits the functional acknowledgment at the interchange level of the document.
    Group Splits the functional acknowledgment at the group level of the document.
    Transaction Splits the functional acknowledgment at the transaction level of the document.
    Note
    • For custom user-specific EDITPA, if you do not select any option for splitFAOption, the default TPA value is used for processing the document.
    • When splitFAOption value is Group or Transaction, the value for FAGeneration/deliverFA must be `false’. To deliver the FA, create a custom processing rule.
    • When the splitFAOption value is Transaction and the FAReconciliation is true, IBM webMethods B2B creates an entry on the FAReconciliation page for the X12 documents with 997 doctype. Ignore this entry in the FA reconciliation for X12 documents, as the FA reconciliation for X12 happens at the group level.
    • When using the webMethods.io B2B connector in IBM webMethods Integration, submitting an EDI payload through the submit operation does not automatically generate a functional acknowledgement (FA). The generation of the FA does not depend on the TPA parameter autoGenerateFA of IBM webMethods B2B. To auto-generate FA when you submit the EDI payload, add the field autoGenerateFA in the params input of the submit operation, set the value to true, and then run the operation.

    Control Number Management Variables

    ControlNumberManagement/ValidateInboundEnvelopeControlNumbers

    Default: false

    The ControlNumberManagement/ValidateInboundEnvelopeControlNumbers variable indicates whether you want the module to validate and track control numbers in the interchange headers of inbound EDI documents.

    Value Description
    true Validates and tracks control numbers in the interchange headers of inbound EDI documents.
    false Does not validate or track control numbers in the interchange headers of inbound EDI documents.

    ControlNumberManagement/ValidateInboundGroupControlNumbers

    Default: false

    The ControlNumberManagement/validateInboundGroupControlNumbers variable indicates whether you want IBM webMethods B2B to validate and track control numbers in the group headers of inbound EDI documents.

    Value Description
    true Validates and tracks control numbers in the group headers of inbound EDI documents.
    false Does not validate or track control numbers in the group headers of inbound EDI documents.

    ControlNumberManagement/duplicateControlNumberAction

    Default: Error & Continue

    The ControlNumberManagement/duplicateControlNumberAction variable indicates the action you want IBM webMethods B2B to take, when it encounters a duplicate control number in an inbound document while validating interchange and/or group control numbers.

    Value Description
    Error & Continue Logs the error and then continues to process the EDI document that contains the invalid control number normally.
    ProcessNormally Logs a warning and processes the EDI document that contains the invalid control number normally.
    Reject Logs the error and does not process the document normally. IBM webMethods B2B does not split the EDI document. Typically, IBM webMethods B2B splits an inbound EDI based on the EDITPA splitOption variable and uses the documents it splits for processing. However, if you set the action to Reject, IBM webMethods B2B processes the document without splitting it. Additionally, IBM webMethods B2B sets the custom attribute EDI Status to Duplicate Control Number. You can use the custom attribute EDI Status in processing rule criteria. You should create a processing rule to handle this rejected document.
    You can force processing of the duplicate document later, if you want.

    ControlNumberManagement/outOfSequenceControlNumberAction

    Default: Error & Continue

    The ControlNumberManagement/outOfSequenceControlNumberAction variable indicates the action you want IBM webMethods B2B to take, when it encounters an out-of-sequence control number in an inbound document while validating interchange and/or group control numbers.

    Value Description
    Error & Continue Logs the error, and then continues to process the EDI document that contains the invalid control number, normally.
    ProcessNormally Logs a warning and processes the EDI document that contains the invalid control number, normally.
    Reject Logs the error and does not process the document normally. IBM webMethods B2B does not split the EDI document. Typically, IBM webMethods B2B splits an inbound EDI based on the value set for the EDITPA splitOption variable and processes the document accordingly. However, if you set the action to Reject, IBM webMethods B2B processes the document without splitting. Additionally, IBM webMethods B2B sets the custom attribute EDI Status to Duplicate Control Number. You can use the custom attribute EDI Status in the processing rule criteria. You should create a processing rule to handle this rejected document.
    You can force processing of the duplicate document later, if you want.

    ControlNumberManagement/VDA/validateStructure

    Default: false

    Indicates whether you want wbMethods.io B2B to validate the structure of inbound VDA documents.

    Value Description
    true Validates the structure of inbound VDA documents.
    false Does not validate the structure of inbound VDA documents.

    BatchCriteria Variables

    Batching involves grouping together transactions from all queued EDI documents. Specify which fields of EDI document to use to batch the transactions.

    BatchCriteria/useDefault

    Default: true

    Indicates whether to consider only the standard fields for sorting the documents in the batching process.

    Value Description
    true Considers only the standard fields for sorting the documents in the batching process.
    false Considers the standard fields and all the other fields set to true in UNB, UNG, ISA, and GS records for sorting the documents in the batching process.

    BatchCriteria EDITPA Variable

    IBM webMethods B2B considers the following standard fields for sorting the EDIFACT documents:

    Value Description
    UNB/UNB02/S00202 The sender qualifier of the EDIFACT document.
    UNB/UNB02/S00201 The sender ID of the EDIFACT document.
    UNB/UNB03/S00302 The receiver qualifier of the EDIFACT document.
    UNB/UNB03/S00301 The receiver ID of the EDIFACT document.
    UNB/UNB11 The mode of the EDIFACT document.
    UNG/UNG07/S00802 The version of the EDIFACT document.

    IBM webMethods B2B considers the following standard fields for sorting the X12 documents:

    Value Description
    ISA/ISA05 The sender qualifier of the X12 document.
    ISA/ISA06 The sender ID of the X12 document.
    ISA/ISA07 The receiver qualifier of the X12 document.
    ISA/ISA08 The receiver ID of the X12 document.
    ISA/ISA15 The mode of the X12 document.
    ISA/ISA12 The version of the X12 document.

    IBM webMethods B2B considers the following standard fields for sorting the EDIFACT documents:

    Value Description
    UNG/UNG02/S00601 The group sender of the EDIFACT document.
    UNG/UNG03/S00701 The group receiver of the EDIFACT document.
    UNG/UNG06 The control agency code of the EDIFACT document.
    UNG/UNG07/S00801 The message version number of the EDIFACT document.
    UNG/UNG07/S00802 The message release number of the EDIFACT document.
    UNG/UNG07/S00803 The message association assigned number code of the EDIFACT document.
    UNG/UNG01 The group type of the EDIFACT document.

    IBM webMethods B2B considers the following standard fields for sorting the X12 documents:

    Value Description
    GS/GS02 The group sender of the X12 document.
    GS/GS03 The group receiver of the X12 document.
    GS/GS08 The version of the X12 document.
    GS/GS01 The group type of the X12 document.

    persistOriginalEnvelope Variable

    persistOriginalEnvelope

    Default: false

    The persistOriginalEnvelope variable indicates whether to persist the original incoming EDI envelope in IBM webMethods B2B before IBM webMethods B2B starts processing the EDI envelope.

    When IBM webMethods B2B receives an EDI document from a partner, it processes the transactions first, the groups next, and the envelope last. While processing a large document, if IBM webMethods B2B fails to process the entire inbound document, it cannot retrieve the original EDI document received from the partner because the envelope is processed last. IBM webMethods B2B cannot track these unprocessed inbound documents because the original EDI document received from the partner is not persisted in IBM webMethods B2B by default.

    When you choose to persist the original incoming EDI document in IBM webMethods B2B before IBM webMethods B2B starts processing the document, even if IBM webMethods B2B fails to process the entire document, you can track the original document in IBM webMethods B2B and reprocess it.

    If persisting each and every EDI document in IBM webMethods B2B before IBM webMethods B2B starts processing it slows down your system performance, you can configure IBM webMethods B2B to process the envelope first by setting the documentPersistOrder variable to EnvelopeFirst. In this case, IBM webMethods B2B does not persist the original incoming EDI document in IBM webMethods B2B. If IBM webMethods B2B fails to process the entire inbound document, you can still retrieve the details of the original EDI document received from the partner.

    Value Description
    true Before processing the document, IBM webMethods B2B persists the original incoming EDI document with the following attribute values:
    Processing Status = NEW User Status = Original EDI Envelope EDI Status = Persisted
    When IBM webMethods B2B does not completely process the inbound document, then it does not delete the original document persisted. Documents containing the attribute values mentioned above identify that the corresponding document was not processed completely. Resubmit these original documents to IBM webMethods B2B for reprocessing.
    When IBM webMethods B2B successfully processes the inbound document, that is, after all the transactions, groups, and envelope of the document are processed, the additional document persisted in IBM webMethods B2B is deleted.
    Note
    When the value of the documentPersistOrder EDITPA variable is EnvelopeFirst, IBM webMethods B2B does not persist the original EDI envelope in IBM webMethods B2B before processing the document even if you set the value of the persistOriginalEnvelope variable to true.
    false IBM webMethods B2B does not persist the original inbound EDI envelope before processing the document. This is the default.

    documentPersistOrder Variable

    documentPersistOrder

    Default: EnvelopeLast

    The documentPersistOrder variable indicates the order in which the EDI documents are submitted to IBM webMethods B2B.

    Value Description
    EnvelopeLast IBM webMethods B2B submits the envelope of the EDI document after submitting the transactions and groups. This is the default option. IBM webMethods B2B submits the EDI documents in the following order:
    1. Transactions
    2. Groups
    3. Envelope

    When the persistOriginalEnvelope variable is set to false, if IBM webMethods B2B fails while submitting large EDI documents, you cannot retrieve the original EDI document received from the partner because IBM webMethods B2B submits the envelope last.
    EnvelopeFirst IBM webMethods B2B submits the envelope of the EDI document before submitting the groups and transactions. IBM webMethods B2B submits the EDI documents in the following order:
    1. Envelope
    2. Groups
    3. Transactions

    Even though the persistOriginalEnvelope variable is set to true, IBM webMethods B2B does not persist the original inbound EDI document before processing the document. Because IBM webMethods B2B submits the envelope first, you can track the original inbound EDI document at any time until processing is complete.

    Note
    When you use EnvelopeFirst for EDITPA, it does not persist the envelope. To store the envelope, you need to select EnvelopeLast in the configuration. This is applicable only to VDA documents.

    Working with RNIF TPA Parameters

    TPA Parameters

    TPA Section Field Description
    ProcessInfo TransportVersion Version of the transport protocol.
    SenderClassification Business classification of the sender (for example, manufacturer, distributor, or customs broker). This is populated in the GlobalPartnerClassificationCode tag describing the fromPartner in the service header.
    For information about the valid values, see the fromPartner element details in the PIP specification corresponding to the executing PIP, activity, or action.
    Note
    This field is available only for RNIF version 1.1.
    ReceiverClassification Business classification of the receiver (for example, buyer). This is populated in the GlobalPartnerClassificationCode tag describing the toPartner in the service header.
    If the current message is a signal, the value of the fromPartner in the signal must be the same as that of the toPartner in the Action to which this signal is replying.
    For information about the valid values, see the toPartner element details in the PIP specification corresponding to the executing PIP, activity, or action.
    Note
    This field is available only for RNIF version 1.1.
    Sign Indicates whether the outbound RosettaNet PIP document for the conversation should be signed. Valid values are Yes or No.
    SignatureRequired Indicates if the inbound PIP document should contain your trading partner’s signature. Valid values are Yes or No.
    HashAlgorithm Algorithm used to generate the RosettaNet Message Digest (MD5 or SHA-1).
    Note
    MD5 is not supported for RNIF version 2.0. Even if MD5 is selected for RNIF version 2.0, SHA-1 will be used.
    SenderFocalRole This is populated in the GlobalPartnerRoleClassificationCode tag describing fromRole in the service header. Additionally, this is also populated in the GlobalBusinessServiceCode tag describing fromService in the service header.
    For valid values, see the fromService and fromRole details in the PIP specification corresponding to the executing PIP, activity, or action.
    ReceiverFocalRole This is populated in the GlobalPartnerRoleClassificationCode tag describing toRole in the service header. Additionally, this is also populated in the GlobalBusinessServiceCode tag describing toService in the service header.
    If the current message is a signal, the value of fromService must be the same as toService in the action to which this signal is replying.
    For valid values, see the toRole and toService details in the PIP specification corresponding to executing PIP, activity, or action.
    Note
    Focal roles must be set correctly before running a transaction otherwise the transaction fails. The sender and receiver focal roles are reversed in the TPAs of the two trading partners exchanging documents for a two action PIP. For example, the focal role in the TPAs for Partner A, acting in role X, and Partner B, acting in role Y, would be as follows:
  • Partner A TPA: SenderFocalRole = X, ReceiverFocalRole = Y
  • Partner B TPA: SenderFocalRole = Y, ReceiverFocalRole = X
    Focal roles are an important part of the ConversationID. The ConversationID is generated internally, in the format: Initiator DUNS-%%-UniqueID-%%-SenderFocalRole (where “-%%-” is used as the separator).
    		•
    PIPInfo ProcessCode Code or name of the PIP, such as 3A4.
    ProcessVersion Version of the PIP process, such as 1.1 or 1.4.
    ProcessDescription Description of the PIP process (for example, the description of PIP3A4 is Request Purchase Order).
    TransactionCode Transaction associated with each RosettaNet PIP document.
    ActionCode Query action associated with each RosettaNet PIP document.
    ResponseActionCode Response action associated with each RosettaNet PIP document.
    NSDecls XML namespace declaration with the name and value that is added to the XML payload.
    PayloadValidation Indicates whether schema validation for PIP payload is required. Valid values are:
  • Inbound. Set this value for inbound message payload validation.
  • Outbound. Set this value for outbound message payload validation.
  • Both. Set this value for both inbound and outbound message payload validation.
  • None. Set this value when payload validation is not required.

    The system generates a maximum of 100 validation errors, and you can examine them in the Payload Validation Errors content part of a Rosettanet transaction.
    		•
    UsageCode Indicates if the RosettaNet conversation is in test or production mode. Valid values are Test or Production.
    SendAcknowledgment Indicates if an acknowledgment must be sent for the PIP document you received.
    RNIF 2.0 Encoding Specifies how to encode MIME parts.
    Note
    Use base64 and uuencode encoding for binary content messages.
    EncryptPayload Indicates whether to encrypt the outbound RosettaNet payload. Valid values are Yes or No.
    EncryptHeader Indicates whether to encrypt the service header of the RosettaNet PIP document. Valid values are Yes or No.
    Note
    You cannot encrypt the service header alone, without encrypting the payload. To encrypt the payload and service header, set the value of EncryptPayload and EncryptHeader parameters as Yes.
    EncryptionAlgorithm Algorithm used to encrypt the outbound RosettaNet PIP document. Valid values are Triple DES, RC2, and DES.
    RC2EncryptionKeyLength Length (in bits) of the RC2 encryption key. Valid values are 128, 64, and 40.
    CompressContent Indicates whether to compress the outbound document. Valid values are Yes or No.
    sync Indicates whether to send response or receipt acknowledgment synchronously. Valid values are Yes or No.
    Note
    If you are using a synchronous PIP, for example, PIP 2A9, set the value of sync parameter as Yes.

    Working with AS4 TPA Parameters

    TPA Parameters

    AS4 TPA Variable Description
    agreement URI of the location that contains the partner agreement.
    mepBinding Messages exchange definition between two trading partners.
    initiator Information that identifies the initiator of the message exchange.
    responder Name of the responder.
    legs Processing, transportation binding, and business information parameters.
    payloadService Configurable compression and decompression of application payloads.
    splitting The sending Messaging Service Handler (MSH) splits the message into multiple fragments during the send operation of a large user message.
    allowEmptyConversationId Allows an empty conversation ID.

    agreement

    URI of the location that contains the partner agreement.

    mepBinding

    Defines how messages are exchanged between two trading partners. Select one of the following MEP types:

    For details see Message Exchange Patterns.

    initiator

    Information that identifies the initiator of the message exchange. Configure the following initiator parameters:

     
    Parameter Description
    id External ID of the initiating Messaging Service Handler (MSH). The contents of this parameter map to the element Messaging/UserMessage/PartyInfo/From/PartyId.
    type External ID type of the initiating MSH. For example, DUNS.
    role URI of the location where the agreement is stored.
    authorization User credentials the pull signal receiver needs to authorize the pull signal. Specify the following:
      Field Description
      username Username to authorize the pull signal.
      password Password to authorize the pull signal.
    host Indicates whether the partner profile is the host for a document exchange. Possible values are:
    • true. The certificates associated with the partner is selected. Configure this parameter only when the IBM webMethods B2B partner profile is not the enterprise profile during a document exchange between two partners.
    • false.The certificates associated with the partner is not selected.
    Note
    Ensure that you configure either the initiator or the responder TPA parameter as the host.

    responder

    Identifies the responder.
    Configure the following responder parameters:

     
    Parameter Description
    id External ID of the responding MSH, as defined in the partner profile.
    type External ID type of the responding MSH, as defined in the partner profile. For example, DUNS.
    role URI of the location where the agreement is stored.
    authorization User credentials the pull signal receiver needs to authorize the pull signal. Specify the following:
      Field Description
      username Username to authorize the pull signal.
      password Password to authorize the pull signal.
    host Indicates whether the partner profile is the host or not for a document exchange. Possible values are:
    • true. The certificates associated with the partner is selected. Configure this parameter only when the IBM webMethods B2B partner profile is not the enterprise profile during a document exchange between two partners.
    • false.The certificates associated with the partner is not selected.
    Note
    Ensure that you configure either the initiator or the responder TPA parameter as the host.

    legs

    Defines processing, transportation binding, and business information parameters. Add one or more legs by clicking icon.
    Click icon to add a leg before the current leg.

    Configure the following leg parameters:

    Parameter Description
    label MEP leg name.
    protocol The type of transport between two MSHs and information related to the MSHs.
    businessInfo Message exchange service information for a pair of partners.
    errorHandling AS4 report errors.
    security Secures your AS4 message exchange.
    receptionAwareness When enabled, an initiating MSH sends a user message to the responding MSH.

    Configuring an MEP label

    To configure an MEP label, select one of the following:

    Configuring protocol parameters

    To configure the type of transport between two MSHs and information related to the MSHs:

    Parameter Description
    address Endpoint URI of the responding MSH. For example, http://host:port/ws/msh/receive
    username Username to authenticate the access to the partner’s endpoint URI.
    password Password to authenticate the access to the partner’s endpoint URI.
    addActorOrRoleAttribute Specifies whether the role attribute is added to the message header. Possible values are:
    • true. The role attribute is added to the message header.
    • false. The role attribute is not added to the message header.

    Configuring businessInfo parameters

    To configure message exchange service information for a pair of partners:

    Parameter Description
    service URI of the service that processes the message.
    serviceType Name of the service type that indicates how the sender and receiver interprets the service element. If you do not enter a value for this parameter, the service parameter must be a URI.
    action URI of the element that identifies an operation or an activity within a service.
    properties Properties required in the message. If the required properties are missing, the processing of the message stops, and an error is returned. Click icon and configure the following parameters: name, description, and required.
    mpc Message Partition Channel (MPC) identifier. The user message or signal uses this MPC.
    extendedInfo Configure multiple message exchange: service, serviceType, and action.

    Configuring errorHandling

    When you want IBM webMethods B2B AS4 report errors, configure the error handling TPA parameters in the requestUM or replyUM leg for a user message and in the requestSM leg for a pull signal.

    Configure the following parameters:

    Parameter Description
    senderErrorsTo Address or comma-separated list of addresses, to send the ebMS errors that are generated by the sending MSH.
    receiverErrorsTo Address or comma-separated list of addresses, to send the ebMS errors that are generated by the receiving MSH.
    Note
    If you want to enable basic authentication for an endpoint URL, use the username and password from the protocol section of the leg parameter.
    asResponse Select if processing errors at the receiver end are reported on the back channel of erroneous messages. Possible values are:
    • true. Errors are reported on the back channel. This is the default.
    • false. Errors are reported to the receiverErrorsTo address.
    missingReceiptNotifyProducer (Optional). Indicates whether an error signal notification is generated and sent to the producer when a receipt is not received from the partner for the message sent. The error message is sent to the address configured in the senderErrorsTo parameter. Possible values are:
    • true. Error reports are generated.
    • false. Error reports are not generated. This is the default.
    Note
    In the requestUM leg, when missingReceiptNotifyProducer is set to true, sendReceipt must be set to true and replyPattern can be set to response or callback. Where, for response, no additional settings are required and for callback, set replyTo and replyPattern.
    • For One-Way/Push, either response or callback can be set.
    • For One-Way/Pull, only callback can be set.
    • For Two-Way/Push-Pull, only response can be set.
    missingReceiptNotifyProducer cannot be configured in the replyUM leg.

    Configuring security

    To secure your AS4 message exchange, configure the security TPA parameters in the requestUM or replyUM leg for a user message and in the requestSM leg for a pull signal.

     
    Parameter Description
    enableSecurity Enable or disable security.

    Possible values are:

    • true. Security is enabled.
    • false. Security is disabled. This is the default.
    includeTimeStamp Includes time stamp in the security header.

    Possible values are:

    • true. Time stamp is included in the security header.
    • false. Time stamp is not included in the security header. This is the default.
    x509 Information required to sign and encrypt an AS4 message using the WSS X.509 Certificate Token Profile . Configure the following parameters:
      Field Description
      sign Specify if the message is signed and which parts of the message is signed. When you use your own policy for security settings, the values of the sign parameters are ignored. Configure the following parameters:
        Field Description
        enableSign Whether signing is enabled.

    Possible values are:

    • true. Signing is enabled.
    • false. Signing is disabled. This is the default.
        certificateId (Optional). The certificate ID to use for signing or verifying a signature for a message. The partner certificate ID must be used while receiving a message. You can view the certificateId for the configured certificates from the partner's certificate tab.
        element The XPath of each element that needs to be signed. For example, to sign the Timestamp element, add /soapenv:Envelope/soapenv:Header/Messaging/UserMessage/MessageInfo/Timestamp. Click icon to configure multiple element paths that need to be signed.
        attachments Indicates whether signing of the attachments for a message is enabled. Possible values are:
    • true. Signing of the attachments of a message is enabled.
    • false. Signing of the attachments of a message is disabled. This is the default.
        signReceipt (Optional). Whether signing of the receipt is enabled. Possible values are:
    • true. Signing of the receipt is enabled.
    • false. Signing of the receipt is disabled. This is the default.
    Note
    If enableSign is set to false and signReceipt is set to true, the receipt will not be signed.
        receiptCertificateID (Optional). The certificate ID to use for signing the receipt.
        signReceiptBody Indicates whether signing the receipt body is enabled. Possible values are:
    • true. Signing of the receipt is enabled.
    • false. Signing of the receipt is disabled. This is the default.
    Note
    This parameter can be enabled only if signReceipt is enabled.
      encrypt Whether the message is encrypted and which parts of the message is encrypted.
    Note
    When you use your own policy for security settings, the values of the encrypt parameters are ignored.
        Field Description
        enableEncrypt Indicates whether encryption is enabled. Possible values are:
    • true. Encryption is enabled.
    • false. Encryption is disabled. This is the default.
        certificateId (Optional). The certificate ID to use for encrypting or decrypting a message. The partner certificate ID must be used for encryption while sending a message. The certificate ID must be used for decryption. You can view the certificateId for the configured certificates from the partner's certificate tab.
        element The XPath of each element that needs to be encrypted. For example, to encrypt the Timestamp element, add /soapenv:Envelope/soapenv:Header/Messaging/UserMessage/MessageInfo/Timestamp. Click icon and configure the element to be encrypted.
        attachments Indicates whether encrypting the attachments of a message is enabled. Possible values are:
    • true. Encrypting of the attachments of a message is enabled.
    • false. Encrypting of the attachments of a message is disabled. This is the default.
        encryptBody Indicates whether to encrypt the body of a message or not. Possible values are:
    • true. Enables encryption of the message body. This is the default.
    • false. Disables encryption of the message body.
      algorithmSuite Specifies the algorithm suite to be used for signing and encrypting.
    For more information about algorithm suites, see Using Algorithm Suites
    usernameToken Information needed to authenticate the AS4 message.

    Configure the following parameters:
      Field Description
      username User name to authenticate the message
      password Password to authenticate the message.
      hashpassword Indicates whether password hashing is enabled. Possible values are:
    • true. Password hashing is enabled.
    • false. Password hashing is disabled. This is the default.
    policy (Optional). Policy xml content. The policy content must adhere to the format specified in OASIS WS-SecurityPolicy.
    Note
    • The value you provide for the policy takes precedence over other security parameters.
    • If the content of the policy parameter requires either signature or encryption, then the enableSign or enableEncrypt option, or both must be enabled.
    policyStandard (Optional). Specify the policyStandard to be used. Possible values are:
    • Default. Standard policies are used. This is the default.
    • ENTSOG. ENTSOG specific policies are used.
    pmodeAuthorize Indicates whether to authorize the messages on the MEP leg for processing. Possible values are:
    • true. Messages are authorized for processing.
    • false. Messages are not authorized for processing. This is the default.
    receipt Information that identifies how receipts are handled.

    Configure the following parameters:
      Field Description
      sendReceipt Indicates whether a receipt (Receipt ebMS signal) is sent. Possible values are:
    • true. A receipt is sent.
    • false. A receipt is not sent. This is the default.
      replyPattern The reply pattern of the receipt signal. Specify one of the following:
    • response. IBM webMethods B2B sends the receipt on the back channel. This reply pattern can only be used with the One-Way/Push MEP. This is the default.
    • callback. IBM webMethods B2B sends the receipt signal as a separate request.
      replyTo The endpoint URL to which the receipt is sent. You must configure this parameter when replyPattern is set to callback.
    Note
    If you want to enable basic authentication for an endpoint URL, use the username and password from the protocol section of the leg parameter.
      nonRepudiation Indicates whether the hash values for the digests in the user message should be included in the receipt. Possible values are:
    • true. Hash values are included in the receipt.
    • false. Hash values are not included in the receipt. This is the default.

    Configuring receptionAwareness

    If reception awareness is enabled, an initiating MSH sends a user message to the responding MSH.

    Duplicate detection detects a duplicate user message with the same UserMessage/MessageInfo/MessageId as a previous message. When a duplicate message is received, the message is flagged as duplicate and UserStatus in Trading Networks transaction analysis page is updated to DUPLICATE_RECEIVED.

    Configure AS4 reception awareness TPA parameters in the requestUM leg.

    Specify the following parameters:

     
    Parameter Description
    enabled (Optional). Select true to enable and false to disable reception awareness. The default is set to false.
    retry Select parameters that control push retry.
      Field Description
      enabled Select true to enable and false to disable retry. The default value is false.
      retryParameters Configure the following retryParameters that controls push retry:
        Field Description
        maxRetries Type the maximum number of times IBM webMethods B2B tries to resend a message.
        period Type the length of time, in seconds, IBM webMethods B2B waits between retry attempts.
    duplicateDetection Select parameters that control duplicate detection.
      Field Description  
      enabled Select true to enable and false to disable duplicate detection.
      checkWindow Length of time, in seconds (S) or days (D), that a message ID is retained in the cache and checked for duplicate incoming message IDs (for example, 4320000S or 5D).
      maxSize The maximum size, in bytes, of an incoming duplicate message that IBM webMethods B2B saves. When the size of the incoming duplicate message exceeds this value, the duplicate message is not saved in the Trading Networks database and an error is logged.

    payloadService

    IBM webMethods B2B is capable of providing configurable compression and decompression of application payloads. AS4 messages that contain compressed or application payloads are built according to the SOAP with Attachments specification. Each compressed payload is carried in its own MIME body part.

    When you want to send a compressed payload, set the PMode.PayloadService.CompressionType P-Mode parameter to application/gzip, as described below. Enabling this P-Mode parameter indicates to the sending MSH that the outgoing message payloads should be compressed before sending. Therefore, the receiving MSH must decompress the payload part before it delivers the message to the receiver.

    Note
    When the incoming message contains a compressed payload part(s), the receiving MSH decompresses the payload irrespective of the value of the TPA’s CompressionType P-Mode parameter.

    Specify one of the following parameters:

    Parameter Description
    compressionType Specify one of the following:
    • none. Payload compression is disabled. This is the default.
    • application/gzip. Payload compression is enabled.
    extractAttachment Configure IBM webMethods B2B to extract attachments in ebMS 3.0 user message as a separate transaction. Possible values are:
    • true. Attachments in ebMS 3.0 user message are extracted as a separate transaction.
    • false. Attachments in ebMS 3.0 user message are not extracted. This is the default.

    Note
    extractAttachment is supported only for XML and EDI document types.

    splitting

    Message splitting and joining involves two related operations. During the send operation of a large user message, the sending MSH splits the message into multiple fragments.

    Specify the following parameters:

    Parameter Description
    enabled (Optional). Specify one of the following:
    • true. Splitting is enabled.
    • false. Splitting is disabled. This is the default.
    fragmentSize The size of each fragment, in bytes. For example, if fragmentSize is defined as 1000 bytes and the message is 2050 bytes, the message is split into two fragments of 1000 bytes each, and one fragment of 50 bytes. If the message is 900 bytes, one fragment of 900 bytes is sent.
    joinInterval The maximum time, in seconds, to expect and process additional fragments after the first fragment is received.

    allowEmptyConversationId

    (Optional). Allows empty conversation ID. allowEmptyConversationId parameter is added in com.wm.estd.as4.documents.pmode:PMode document. By default, this parameter is not set. If the value is not set for this parameter in the Trading Partner Agreement, then the property as4.message.emptyConversationId is used.

    Possible values are:

    Partner Profile ID Types Mapping for EDI Documents

    The following table lists the ID type mapping found in EDI documents to represent the identity types in partner profiles:

    Standard Code ID Type
    01 DUNS
    02 SCAC
    03 FMC
    04 IATA
    5 INSEE SIRET
    07 GLN
    08 UCC ID
    09 X.121
    10 DoD Code
    11 DEA
    12 Phone
    13 UCS Code
    14 EAN
    15 PAS Code
    16 DUNS+4
    17 ABA Routing
    18 AIAG
    19 EDICA ID
    20 HIN
    21 IPEDS
    22 INSEE SIREN
    23 NCES
    24 ATP
    25 4-Digit Code List of Postsecondary Institutions
    26 Stat of List of Postsecondary Institution
    27 Carrier ID by HCFA
    28 Fiscal Intermediary ID by HCFA
    29 Medicare Provider and Supplier ID by HCFA
    30 ISO 6523
    31 DIN
    32 FEIN
    33 BfA
    34 Medicare Provider and Supplier ID by states
    35 Stat College Student Info System Institution Codes
    36 Stat University Student Info System Institution Codes
    37 Society of Preperty Info Compilers and Analysts
    38 6-Digit Code List of Secondary Institutions
    51 GEIS
    54 BdDB
    55 Bank ID
    91 seller agent
    92 buyer agent
    AM AMECOP ID
    NR NRMA
    SA ID by SAFER
    SN Standard Address Number
    ZZ, ZZZ Mutually Defined

    Supported TLS Versions and Algorithm Suites

    Important
    IBM recommends that you use only strong ciphers for your business communications.

    TLS 1.2

    The following algorithms and cipher suites are supported in IBM webMethods B2B for TLS 1.2.
    The table lists all the ciphers and algorithms used for outbound documents:

    Algorithms Cipher Suites
    Diffie-Hellman Exchange TLS_DHE_DSS_WITH_AES_128_CBC_SHA
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
    TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
    TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    ECDHE ECDSA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    ECDHE RSA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    ECDH ECDSA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
    TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
    ECDH RSA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
    TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
    TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
    EMPTY TLS_EMPTY_RENEGOTIATION_INFO_SCSV
    RSA TLS_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA256
    TLS_RSA_WITH_AES_128_GCM_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA
    TLS_RSA_WITH_AES_256_CBC_SHA256
    TLS_RSA_WITH_AES_256_GCM_SHA384

    The following table lists all the ciphers and algorithms used for inbound documents:

    TLS 1.3

    The following TLS 1.3 algorithms and cipher suites are supported for outbound runtime calls in IBM webMethods B2B.

    Note
    IBM webMethods B2B does not support TLS 1.3 for inbound HTTPs communication.
    Cipher Suites
    TLS_AES_256_GCM_SHA384
    TLS_CHACHA20_POLY1305_SHA256
    TLS_AES_128_GCM_SHA256
    TLS_AES_128_CCM_8_SHA256
    TLS_AES_128_CCM_SHA256

    Using Algorithm Suites

    The following table lists the algorithm suites:

    Algorithm Suite Name Signing Algorithm Encryption Algorithm
    Algorithm Suite Name Signing Algorithm Encryption Algorithm
    Default sha1 tripledes-cbc
    Basic128 sha1 aes128-cbc
    TripleDes sha1 tripledes-cbc
    Basic128Rsa15 sha1 aes128-cbc
    TripleDesRsa15 sha1 tripledes-cbc
    Basic192Sha256 sha256 aes192-cbc
    Basic128Sha256 sha256 aes128-cbc
    TripleDesSha256 sha256 tripledes-cbc
    Basic128Sha256Rsa15 sha256 aes128-cbc
    TripleDesSha256Rsa15 sha256 tripledes-cbc
    Advanced128Sha256GCM sha256 aes128-gcm
    Advanced256Sha256GCM sha256 aes256-gcm
    Basic256 sha1 aes256-cbc
    Basic192 sha1 aes192-cbc
    Basic256Rsa15 sha1 aes256-cbc
    Basic192Rsa15 sha1 aes192-cbc
    Basic256Sha256 sha256 aes256-cbc
    Basic192Sha256 sha256 aes192-cbc
    Basic256Sha256Rsa15 sha256 aes256-cbc
    Basic192Sha256Rsa15 sha256 aes192-cbc

    Working with IBM webMethods Cloud Container

    Cloud Container provides an execution engine for running integrations used for service orchestration, primarily for existing on-premises customers. To support existing Trading Networks setups, and businesses wanting to migrate the existing integration logic involving flow services, mappings or transformations and document references to cloud, Cloud Container provides a mechanism to host them as-is by deploying them directly from the webMethods on-premise setups. Click site for more information on Cloud Container.

    If you have a valid IBM webMethods Cloud Container subscription, then the configuration page would appear under the Settings > Extensions menu, for you to configure the IBM webMethods Cloud Container instance to which you want to connect through IBM webMethods B2B.

    If your IBM webMethods Cloud Container subscription expires, then you can re-subscribe to it using your IBM webMethods iPaaS account by clicking on the app switcher icon.

    Note
    Solutions running on Cloud Container do not support the AS4, RNIF, and cXML document types.

    Before you Begin

    Note the following points:

    To configure an instance of IBM webMethods Cloud Container account

    1. In IBM webMethods B2B, go to Settings icon > Extensions.
    2. Click Add Account.

    3. Type the username and password to connect to the IBM webMethods Cloud Container instance.

      Note
      Only basic authentication with username and password is supported to connect to IBM webMethods Cloud Container instances.

    4. Click Connect.

    To configure Processing Rules to run Cloud Container services

    1. In IBM webMethods B2B, go to Rules icon > Processing rules.

    2. In the Configure actions step, specify the following details for Cloud Container:

      • Solution. Select the solution in which the integration resides.
      • Node. Select the node that contains the integration.
      • Package. Select the package that contains the integration.
      • Service. Select the service you want to run when the processing rule is triggered.
      • Execution mode. IBM webMethods B2B can invoke the service in one of the following ways:
        • Asynchronous. IBM webMethods B2B continues with the remaining processing actions immediately. If there are no subsequent processing actions, IBM webMethods B2B returns to the caller that sent the document for processing. You can track the result of this type of execution in the Course of transaction section.
        • Synchronous. Before performing the rest of the processing actions, IBM webMethods B2B waits for the service to complete before returning to the caller that sent the document for processing. You can track the result of this type of service in the Course of transaction section.
        • Reliable. Allows IBM webMethods B2B to automatically retry running the failed service by creating a task to track the completion. When IBM webMethods B2B attempts to execute a service and if the service fails, IBM webMethods B2B retries running the service subsequently until it succeeds or until it reaches the maximum retry limit. If the service execution reaches the maximum retry limit without succeeding, IBM webMethods B2B marks the service execution task as failed icon.

      • Service input. (Optional) Specify specific service input parameters to execute the service when a processing rule is triggered.

        You cannot update values for bizdoc, sender, and receiver and any fields of object type and object list.

    To configure Trading Partner Agreements to refer to Business Document Types on Cloud Container

    1. In IBM webMethods B2B, go to Agreements icon > TPA Templates > Add Template.
    2. In the Create New Template dialog box, specify the Solution name and the Node name along with the Packages and Document type with which you want to create the TPA template.

    Troubleshooting Tips

    If you are unable to access the IBM webMethods Cloud Container instance, ensure that you have performed the following tasks:

    The following table describes how IBM webMethods B2B handles error scenarios:

    Scenario Behavior
    You do not have a IBM webMethods Cloud Container subscription You will not see the option to access IBM webMethods Cloud Container Solutions.
    Your IBM webMethods Cloud Container subscription has expired but you have configured IBM webMethods B2B assets to access the solutions All the configurations in IBM webMethods B2B are retained, but display runtime failures. You must remove these details from the processing rule action to avoid this error.
    You do not configure a IBM webMethods Cloud Container account, although you have a valid subscription IBM webMethods Cloud Container configurations in IBM webMethods B2B appear, but do not work during runtime. An error appears.
    You use invalid IBM webMethods Cloud Container account credentials IBM webMethods Cloud Container configurations in IBM webMethods B2B appear, but do not work during runtime. An error appears.
    If the solution, node, package or service or document type (for TPAs) is moved in IBM webMethods Cloud Container. An error appears. You must reconfigure these details in the processing rule action (or TPA template) to avoid this error.
    Note
    When you import a TPA or a Processing rule from another cloud instance, the references to the IBM webMethods Cloud Container assets are also imported through these assets. But these references would work only if you add the IBM webMethods Cloud Container account in the new cloud instance.