webMethods.io B2B supports a comprehensive list of leading industry-standard EDI documents.
A list of group, envelope, and other native EDI documents appear as default documents on the webMethods.io B2B Business documents page.
EDI documents display information organized in the form of records, composites, and fields:
Add new EDI documents to webMethods.io B2B based on the business needs.
Adding a document in webMethods.io B2B also adds it on webMethods.io Integration. Access these documents on webMethods.io Integration by using the EDI application.
To add an EDI document
Field | Description |
---|---|
Standard | The document standard from the list as required. For a complete list of standard documents, see Supported Business Documents. |
Version | The version of the document standard selected. |
Transaction | The transaction type for the selected document standard and version. |
Page | Activities to perform |
---|---|
Document structure | The document tree view displays the schema of the EDI document. Expand the document tree view and select a node to view the node-specific properties. In the Document definition section, view and search a node by its name, alternate name, or by XPath, and edit its properties. In the Properties section, change the properties associated with composites, records, and fields. For a complete list of properties, see EDI Document Properties. |
Attributes | A list of attributes of the default documents. |
Options | Document options that apply only when the processing rule has any of the preprocessing options set to Defer to business document. |
Next steps
After you add an EDI document of standard type UNEDIFACT, ODETTE, or EANCOM, add a new document with control transaction (CONTRL) for the corresponding standard and version. From the EDI document page, select CONTRL from the Transaction drop-down. This is important to successfully generate and send a functional acknowledgment (FA) to partners. An FA is a type of EDI transaction set that acknowledges the receipt, as well as the structural and syntactical validity of an EDI document.
For example, if you add a UNEDIFACT document of version 02B and transaction type BALANC - Balance message, to add a document with control transaction for this EDI document, perform the following steps:
Field | Value |
---|---|
Standard | UNEDIFACT |
Version | 02B |
Transaction | CONTRL |
Modify or update the following aspects of a business document:
The document properties impact the behavior of each node in an inbound document. For any inbound document that deviates from the properties set for each node, webMethods.io B2B generates appropriate validation errors in the Course of transaction. For information on how to set the validate option, see the webMethods.io Flow Editor Online Help for the Electronic Data Interchange application.
The updates to a business document on webMethods.io B2B are propagated to the webMethods.io Integration instance. Access these documents by using the EDI application on webMethods.io Integration.
To update an EDI document
The EDI document is updated to include the modifications.
You can create custom EDI documents based on standard formats (X12 and UNEDIFACT), including the ability to specify versions and transactions. This allows for the modification of the document structure without changing the original format by leveraging existing EDI standards (X12 and UNEDIFACT), versions, and transactions while referring to previous modifications. This capability facilitates the reuse of customized document structures based on partner specification without changing the original document.
Pre-requisite: You must have administrator privilege to perform this activity.
To customize an EDI document for Existing Business Documents
b. On the left-hand side, select a element to modify the segment and navigate to the element by using the action buttons such as up, down, right(Make the existing element a child element), left(Make the existing element a parent element), add an element(create a new element), delete an element(delete a element), copy, and paste.
Note: You can add a field element only to records and composites.The following table lists the segment type and the relevant action to perform:
Segment type | Actions to perform |
---|---|
Field | 1. Select the segment. 2. Click Add. |
Composite | 1. Select the segment. 2. Click Add. |
Record | 1. Select the segment. 2. Select the child segment type. 3. Select the field name. 4. Click Add. |
Points to note:
To add an Element to a Record or Composite
On the left-hand side, select a element to modify the segment and navigate to the element by using the action buttons and click to add a element.
Note: You can add a element only for records and composites.
The following tables list the document properties based on whether the element you select is a composite, record, or field.
Any inbound document that deviates from the properties you set for each of the elements generates appropriate validation errors in the Course of transaction. For information on how to set the validate option, see the webMethods.io Integration documentation for the Electronic Data Interchange application. The errors that appear in the Course of transaction depend on how the orchestration you define on webMethods.io Integration handles and returns the errors.
Note: For inbound EDI documents, if an attribute is not mandatory and an error occurs during its extraction, the status is set to error instead of a warning.
A few scenarios may require you to perform cross-field validations in the business document schema. For example, a certain condition may be based on another field in the document, or a certain field may need to adhere to a length limit for the business transformation logic to process the document schema appropriately.
Different types of validators are available for records, composites, and fields. Validation is possible for:
The conditional validators are used in conjunction with all other validation attributes and are applied when the document is processed.
Follow the syntax rules created by the EDI Standards bodies ANSI X12 or UN/EDIFACT to specify conditional validators for a record or composite, regardless of the type of document you use.
Anatomy of the Validator Property in an ANSI X12 Document
A conditional validator refers to the location of the field in a definition, not the location of the data in a business document. For example, if you switched the extractors for the first and second field such that the first field extracts the value in Field_II and the second field extracts the value in Field_I , the conditional validator would indicate that if Field_II is present, then Field_I is required.
This indicates that if Field_I is present, then Field_II also must be present. If you switch the position of these fields in the record, you get the following:
This indicates that if Field_II is present, then Field_I also must be present.
The following diagram illustrates the fields of a UN/EDIFACT conditional validator:
The record definition has five fields defined. Each with an Nth Field extractor, the first being field_I , the second field_II and so on. Both of these validators indicate that if Field_I is present, Field_II is required. If Field_III is present, Field_IV and Field_V are required; however, if Field_IV and Field_V are present, Field_III need not be present.
The following table indicates the codes for ANSI X12 and UN/EDIFACT documents based on the values in the above illustrations:
ANSI X12 Rule Name (and Code) | UN/EDIFACT Rule Name (and Code) | Description |
---|---|---|
Required ( R ) | One or more ( D3 ) | At least one of the specified fields must be present. |
ANSI X12 Example: R030405
UN/EDIFACT Example: D3(030,040,050)
ANSI X12 Example: C030405
If you specify a field value of 00, the extra zeros are trimmed when the value is saved. For example, if you type C030400, the fields: 03, 04, and 00 are interpreted in pairs. 00 is trimmed as applying the conditional validator does not alter it.
UN/EDIFACT Example: D5(030,040,050)
ANSI X12 Example: E030405
UN/EDIFACT Example: D4(030,040,050)
ANSI X12 Example: L030405
UN/EDIFACT Example: D6(030,040,050)
ANSI X12 Example: P030405
UN/EDIFACT Example: D2(010,020)
UN/EDIFACT Example: D1(030,040,050)
UN/EDIFACT Example: D7(030,040,050)
Code list validators are used to validate field lengths or code lists when webMethods.io B2B processes a document.
When you select the code list validator for a field or a record, webMethods.io B2B appends /code in the xPath query for the attributes you want to extract. For example, /ST/ST01/code.
Modifying a validator for a field or a record from or to a code list validator impacts the existing attribute queries and these queries require updates accordingly.
In the EDI business document specify the system and custom document attribute values to extract from documents that match this document type. If you want to transform extracted attributes, use built-in or custom transformations. Add a new attribute or replace an existing one.
On the document details page, click Attributes on the left navigation panel.
To add an attribute, select a node in the left panel for which you want to define an XPath query. Click Add To Attributes and provide the following information in the Add extracted attribute dialog box:
To replace an existing attribute, select a node for which you want to replace an attribute. Select an existing attribute from the list and click Replace Attribute. If you choose to modify the attribute name and click Replace. The XPath expression of the selected attribute is replaced with that of the selected node. Click Update to save the modifications.
Restoring a business document to its original state applies to the business document across webMethods.io B2B and webMethods.io Integration instances.
However, the default documents do not have a document structure associated with them, and therefore the modifications you make to them are not propagated to the webMethods.io Integration product instance.
Disable the business document.
To reset an EDI document
The reset operation resets the properties, description, and options for the documents you add.
Important: Resetting a business document on webMethods.io B2B resets the document in the webMethods.io Integration instance as well. Therefore, any orchestration that uses this document in its business logic is impacted and might result in errors.
EDI systems typically work on batch documents. EDI Batching is helpful while delivering documents in a batch rather than delivering EDI documents to the systems in real-time as the documents are received. This feature works irrespective of the underlying inbound or outbound channel configuration for a business partner.
Batching offers the following benefits:
Note: The maximum document size in an EDI Batch Envelope or EDI Batch Group is 4MB.
Documents can be queued and delivered at a later time. And based on the queue schedule information, a scheduler creates a final batch document based on the queue configurations defined during the queue creation. This use case starts when you create a queue with a processing rule. This processing rule helps in queuing the submitted documents on the queue. And the use case ends when a final batch document is routed to a partner using a processing rule.
There are different ways to process the document using queues:
Documents can be processed using queues, when the action in Processing rule is Queue for delivery. There are two ways to do it:
For a receiver’s queue, either associate a General queue or a Partner-specific queue with the partner.
Ensure that you:
While creating a queue, if the Queue for delivery under the create processing rule section is selected, then the processing rule is created along with the queue.
See Creating a General Queue to create a general queue and see Creating a Partner-specific Queue to create a Partner-specific queue.
To deliver documents in batches by configuring queues
To deliver the document
Once the batch scheduler is triggered, it batches the queued documents as per the configuration defined in the queue. It then creates a final batch document with a special attribute to recognize it as EDI batch equals Interchange. You can then create a processing rule with that attribute condition to deliver the document to the intended partner as per the preferred channel.
For example, consider partner A and B. Partner A wants to send a batch document to partner B using a queue. It requires the processing rule (where the processing rule action, Delivery method section is set to Queue for delivery). Once the document is received or generated for partner B, the it gets queued based on the Processing rule criteria and when the final batch document is created and need to be send to partner immediately, then configure a processing rule for this (where, in the Delivery method section, set the Preferred protocol and in Extended criteria set the Attribute field with EDI batch, with the Operator set to Equals and the Value field with Interchange to recognize the EDI document).
Note: For each payload that is queued as a batch document, a task is created. All the tasks are linked to the final EDI batch document. View this in the Task menu of the EDI batch transaction.
Use the Validate Document Structure option to enforce document schema adherence. Recognition of the inbound documents can fail when they do not adhere to the underlying schema. If there are violations, the transaction summary captures them as validation errors. Each of the error corresponds to an error code.
Important: Examine these validation errors in the output of the convertEDIMessagetoDocument operation in webMethods.io Integration.
The following table describes the validation error codes:
Error Code | Description |
---|---|
1 | In the EDI document schema, the Mandatory drop-down menu is set to true for this element, but the element does not occur in the EDI document. |
2 | Reserved for future use. |
3 | Unexpected element. This field is not allowed in the record or composite in which it appears. |
4 | In the EDI document schema, a length validator is specified in the Validator property for this field. The value in the EDI document exceeds the maximum length specified. |
5 | In the EDI document schema, a length validator is specified in the Validator property for this field. The value in the EDI document did not meet the minimum length specified. |
6 | Reserved for future use. |
7 | In the EDI document schema, a code list validator is specified in the Validator property for this field. The value in the EDI document is not listed in the EDI schema as a valid value. |
8 | Reserved for future use. |
9 | Reserved for future use. |
10 | In the EDI document schema, a conditional validator is specified in the Validator property for this composite or record. The contents of this composite or record does not meet the conditional requirements. Note: The errorMessage variable in the convertEDIMessagetoDocument operation contains the number of the condition that failed. If you have a validation string of C010203R0405 and both conditions fail, the error message would state that rules 0 and 1 are violated. If only the second is violated, it states that the rule 1 is violated. |
11 | The record is not defined anywhere in the EDI document schema. This error appears only when you do not specify a Default Record or selected Allow Undefined Data where this record appears in the document. If you specify either of these properties, you do not receive this error. |
12 | The record is defined in this EDI document schema, but it occurs in the document in a location prohibited by the EDI document schema. |
13 | Reserved for future use. |
14 | In the EDI document schema, the number of record instances in the EDI document exceeds the specified maximum number of repeats. This is validated against the Max Repeat property for a particular record. |
15 | Reserved for future use. |
16 | Within a record, this code indicates that the record contains a composite or field error. For a composite, this indicates that the composite contains a subfield error. |
17 | A string could not be formatted into the intended format. A format service reported that the data could not be formatted properly. |
18 | The conditional validation rule requires a field, but that field is not present in the data. |
19 | A field is excluded by a conditional validation rule, but that field is present in the data. |
Add, identify, and process Flat File documents in webMethods.io B2B.
Validate the Flat File documents with the corresponding Flat File connector from webMethods.io Integration.
By default, webMethods.io B2B considers inbound documents with the text/plain content type as Flat File documents.
Complete the following steps for webMethods.io B2B to start recognizing Flat File documents:
webMethods.io B2B instance with administrator privileges.
Add key-value identifiers for a flat file and associate them with an inbound channel so that webMethods.io B2B recognizes the Flat Files based on these identifiers. For detailed steps, see Using Custom Properties to Recognize Flat Files.
Modify or update the Flat File:
Recognize and process inbound Flat File documents and send them to business partners.
The Custom properties you define in the Advanced properties of an inbound channel can be used to recognize and identify the incoming payload of a Flat File document. To use the custom properties for flat files, add them as identifiers or attributes in the corresponding Flat Files.
For more information about these properties, see Supported Channel Types and Details.
Create at least one inbound channel to receive inbound Flat File documents from a trading partner.
webMethods.io B2B uses these properties to recognize the incoming document. Use them either as identifiers or attributes, to extract to perform transformations.
Important: The key-value pairs are case-sensitive and must be a unique set.
The below visual illustrates the flow:
For details on the behavior of flat file resubmission, see Editing and Resubmitting a Business Document.
In webMethods.io B2B, create and define XML documents by referring to an existing document type in webMethods.io Integration.
The Business documents page displays a list of documents that are available in webMethods.io B2B. You can:
In webMethods.io B2B, define various document properties and use them when you create an XML document.
This use case explains how to define an XML document in webMethods.io B2B that refers to an existing document in a selected project from webMethods.io Integration.
In this example, define an XML document purchase_order , which is project-aware of the project B2B_Test in webMethods.io Integration and refers to an existing document docTypeRef_PurchaseOrderType .
Ensure that you have:
To define an XML document that refers to an existing document
This use case explains how to define an XML document from a sample XML document.
The use case starts with a sample XML document based on which you want to define an XML document and ends when you successfully create the XML document.
In this example, define an XML document PurchaseOrder , that is project-aware of the project B2B_Test in webMethods.io Integration and uses a sample XML document PORequest.xml .
Ensure that you have:
To define an XML document from a sample XML document
Note: The sample XML file should have a file size, which is less than or equal to 1 MB.
View this XML document in the list of available documents on the Business Documents page.
Important: After adding XML documents using DTD or XSD or a sample XML, you must explicitly add the processVersion attribute in the pipeline matching step under Identifiers for each of the documents, so that webMethods.io B2B can recognize Rosettanet messages.
With this use case, the respective document type is also created on webMethods.io Integration.
This use case explains how to define an XML document from XML schema.
The use case starts when you have an XML schema based on which you want to define an XML document and ends when you successfully create the XML document.
In this example, define an XML document purchaseorder1 , that is project-aware of the project B2B_Test in webMethods.io Integration and uses an XML schema POAccept.xsd .
Ensure that you have:
To define an XML document from an XML schema
Note: The XML schema file should have a file size, which is less than or equal to 1 MB.
Important: After adding XML documents using DTD or XSD or a sample XML, you must explicitly add the processVersion attribute in the pipeline matching step under Identifiers for each of the documents, so that webMethods.io B2B can recognize Rosettanet messages.
With this use case, the respective document type is also created on webMethods.io Integration.
This use case explains how to define an XML document with a DTD.
The use case starts when you have either a plain DTD document or a DTD document in a compressed zip, or a URL on which a DTD is hosted based on which you want to define an XML document. The use case ends when you create the XML document.
In this example, define an XML document based on a DTD purchaseorder1 , that is project-aware of the project B2B_Test in webMethods.io Integration and uses a DTD POAccept.DTD .
Ensure that you have an existing project in webMethods.io Integration.
To define an XML document with a DTD
Note: The DTD document or Compressed zip containing DTD document should be less than or equal to 5 MB in size.
Important: After adding XML documents using DTD or XSD or a sample XML, you must explicitly add the processVersion attribute in the pipeline matching step under Identifiers for each of the documents, so that webMethods.io B2B can recognize Rosettanet messages.
With this use case, the respective document type is also created on webMethods.io Integration.
Modify or update the following aspects of an XML document:
These properties impact the behavior of each node in an inbound document. Any inbound document that deviates from the properties you set for each of the nodes, generates appropriate validation errors in the Course of transaction.
Note: The updates you make to a business document on webMethods.io B2B are also propagated to the webMethods.io Integration instance.
To update an XML document
For details on the fields and their description, see XML Document Properties
The XML document is updated to include the modifications.
Activate the document and test it.
If you have samples of XML documents webMethods.io B2B processes, test them to determine whether each document:
Ensure that the XML document is in active state.
To test an XML document
Alternatively, browse and select the required .xml file.
webMethods.io B2B displays all document types that match the sample document.
The RosettaNet organization creates and maintains Partner Interface Processes (PIPs) to provide common business-process definitions for all RosettaNet message exchanges.
Note: Extract the contents of the PIP zip folder when the DTD document does not have dependencies.
To add a PIP in DTD format in webMethods.io B2B, see Defining an XML Document by Using a DTD File.
The following sections describe various document properties against which webMethods.io B2B validates any inbound document. Modify any of these properties, as required.
Define XML document types to be general or specific. For example, define an XML document type that recognizes OAG documents, OAG PROCESS_PO_004 documents, or OAG PROCESS_PO_004 documents from a specific sender.
webMethods.io B2B displays a tree view of the referred webMethods.io Integration document in the left panel.
Specify at least one criterion for a document to match a document type. In case of multiple criteria, it must match all the identification criteria you specify. If you specify the Root tag and Doctype criteria, webMethods.io B2B matches inbound XML documents to those criteria first. If these match, webMethods.io B2B also checks the identifying XQL queries and values, and the pipeline matching. Matching criteria for XQL queries and its values is case-sensitive.
Field | Description |
---|---|
Root tag | Specifies the root element for the document type. It is the value that inbound documents must have in the root tag to match the document type. |
Doctype identifier | Specifies the system or public identifier from the DOCTYPE declaration that inbound documents must have to match the document type. For example, to identify a document that has the DOCTYPE declaration , you would type cXML.dtd. |
Identifying queries | Specify that certain nodes must be present for inbound documents to match the document type. You can also specify the values those nodes must have. To do so, define identifying XQL queries. For example: The identifying query below specifies that the OrderRequest tag must be present: /cXML[0]/Request[0]/OrderRequest[0] The identifying query below specifies that the Identity tag, within the Sender tag > Credential tag, must be present and must evaluate to XYZ Steel Company: /cXML[0]/Header[0]/Sender[0]/Credential[0]/XYZ Steel Company Add a new identifier or replace an existing one. To add a new identifier, select a node for which you want to add an identifying query and click Add Identifier. Provide the XPath expression and the value for the expression. Ensure that the length of the XPath is limited to 2,000 characters. Click Add. Click Update to save the modifications. To replace an identifier, for a particular node select an existing identifier and click Replace Identifier. Choose to modify the value and click Replace. The XPath expression of the selected identifier is replaced with that of the selected node. Click Update to save the modifications. |
Pipeline matching | Specify pipeline variables that must be present in the inbound documents to match the document type. Criteria for matching inbound documents to the document type are name/value pairs, where values are optional. The pipeline is a webMethods.io B2B data structure in which input and output values from services of webMethods.io B2B application are maintained. The pipeline starts with the input to a service and collects inputs and outputs from subsequent services. When a service executes, it has access to all data in the pipeline. If you do not specify a value, the document matches the document type if the pipeline has a variable that matches the specified name, regardless of the variable’s value. If you specify a value, the variable must have the specified value. The variables are inserted into the pipeline by the service from webMethods.io B2B application that sends the document to webMethods.io B2B. To add a pipeline variable, click Add Pipeline in the Pipeline matching section on the right. In the Create pipeline match dialog box, type the variable name and optionally, the value. |
In the document type, specify the system and custom document attribute values to extract from documents that match this document type. If you want to transform extracted attributes, use built-in or custom transformations. Add a new attribute or replace an existing one.
On the document details page, click Attributes on the left navigation panel.
To add an attribute, select a node in the left panel for which you want to define an XPath query. Click Add To Attributes and provide the following information in the Add extracted attribute dialog box:
To replace an existing attribute, select a node for which you want to replace an attribute. Select an existing attribute from the list and click Replace Attribute. Modify the attribute name and click Replace. The XPath expression of the selected attribute is replaced with that of the selected node. Click Update to save the modifications.
If an XML document uses namespaces, the elements in that document might be prefixed with a string. When you create XQL queries to identify elements within the document, the XQL queries must include the prefix. If XML documents use equivalent namespaces but have different prefixes, you must define namespace mappings for webMethods.io B2B to locate the nodes identified by the XQL queries. Namespace mappings identify all prefixes that identify the same namespace (that is, point to the same URI).
Include a namespace mapping for each prefix and URI combination that you expect to receive in XML documents from the partners. If webMethods.io B2B receives a document that uses a prefix that is not defined in the namespace mappings table, it performs a literal match of the XQL queries against the document.
On the Options page, define the options and actions, as required:
Field | Description |
---|---|
Enable Processing Rule Routing | Enables processing of documents using pre-processing and processing actions defined in a processing rule. |
If you want to process documents using only pre-processing actions defined in the document type, disable processing rule routing.
To use this action, the document type must specify extraction of the SignedBody and Signature system attributes, and the signature must be a PKCS#7 detached signature of the signed body. In addition, the profile for each partner whose digital signature you want to verify must specify a certificate. webMethods.io B2B ensures that the signed body has not changed by verifying the digital signature. To verify that the sender is who it claims to be, webMethods.io B2B matches the certificate from the digital signature to the certificate in its database for the sender.
You must save a document to the database when you want to:
Choose to save All documents or Only unique documents.
Select whether you want to persist just the Content, Attributes, Activity log or all of them in the saved document.
All the XPath operators and XPath axes can be used to access the nodes. For the complete list of operators and axes on XPath, see the XML Path Language (XPath) 3.0 standards.
The following is an XML document sample used in the examples:
PurchaseOrderRequest> PurchaseOrder> deliverTo> PhysicalAddress> cityName> FreeFormText>Reston VA/FreeFormText> /cityName> addressLine1> FreeFormText>Software AG/FreeFormText> /addressLine1> addressLine2> FreeFormText>11700 Plaza America Drive/FreeFormText> /addressLine2> addressLine3> FreeFormText>Reston VA/FreeFormText> /addressLine3> NationalPostalCode>20190/NationalPostalCode> /PhysicalAddress> /deliverTo> comment> FreeFormText>Comments go here/FreeFormText> /comment> packListRequirements> FreeFormText>Packing List Requirements/FreeFormText> /packListRequirements> totalCost free="noMonetaryValue">6510/totalCost> This is the items array series --> Item 1 --> ProductLineItem> shipFrom> GlobalLocationIdentifier>Warehouse 1/GlobalLocationIdentifier> /shipFrom> ProductQuantity>150/ProductQuantity> LineNumber>1/LineNumber> productUnit> ProductPackageDescription> ProductIdentification> GlobalProductIdentifier>Anvil/GlobalProductIdentifier> PartnerProductIdentification> GlobalPartnerClassificationCode>5644/GlobalPartnerClassificationCode> ProprietaryProductIdentifier>CS-1100/ProprietaryProductIdentifier> /PartnerProductIdentification> /ProductIdentification> /ProductPackageDescription> /productUnit> /ProductLineItem> Item 2 --> ProductLineItem> shipFrom> GlobalLocationIdentifier>Computer Warehouse 1/GlobalLocationIdentifier> /shipFrom> ProductQuantity>120/ProductQuantity> LineNumber>2/LineNumber> productUnit> ProductPackageDescription> ProductIdentification> GlobalProductIdentifier>Hammer/GlobalProductIdentifier> PartnerProductIdentification> GlobalPartnerClassificationCode>5672/GlobalPartnerClassificationCode> ProprietaryProductIdentifier>CS-1150/ProprietaryProductIdentifier> /PartnerProductIdentification> /ProductIdentification> /ProductPackageDescription> /productUnit> /ProductLineItem> /PurchaseOrder> /PurchaseOrderRequest>
The following table lists some path expressions and the result of the expressions based on the sample XML document:
Selects the deliverTo element.
Reston VA Software AG 11700 Plaza America Drive Reston VA 20190
Reston VA
6510 150 120
Computer Warehouse 1 120 2 Hammer 5672 CS-1150
6510
Document attributes identify specific content in the documents when they pass through the network. This specific content in the document may be of your interest in the document. For example, a purchase order number or the account number of a purchaser. You can write specific logic to process a document with a certain purchase order after you extract the attributes of your interest in the document.
The following are a few reasons to extract document attributes:
System attributes are the document attributes that webMethods.io B2B owns. The system attributes are:
System Attribute | Description |
---|---|
Sender ID | Identification of the sender of a document. |
Receiver ID | Identification of the receiver of a document. |
Document ID | Identification of the document. |
User Status | The status that you or a partner associates with the document. |
Conversation ID | Identification within a document that associates this document with other documents in the same business process (or conversation of documents). |
Signed Body | Portion of a document that contains data that is digitally signed. |
Signature | Portion of a document that contains the digital signature of the document. |
Custom Attributes are attributes that you define to identify any other content that you are interested in extracting from the documents. For example, to extract the purchase order number from documents, you might define a document attribute named PO_Number . To extract the total amount of a purchase order, you might define a document attribute named Total_Order_Amount .
Create custom attributes for all the types of documents you expect to receive; attributes are not associated with a specific document type. Later, when you define the document types or add an extended criteria for a rule, you would specify the attributes to extract and to use as criteria.
To create a custom document attribute
These document attributes are used later when you define document types as a criterion to extract the documents. Modify the Document attribute details or change the status of a document attribute by using the Edit () option for the respective attribute.
Note: The name of the custom attribute cannot be $duplicate as it is a parameter name.
When you receive an HTTP header with the prefix x-RN- for an inbound RNIF message, webMethods.io B2B creates a document attribute. The prefix is not case-sensitive. You can view this RNIF-specific attribute in the attribute tab of the Transactions page.
You can use the extracted attributes as extended criteria in processing rules to apply specific logic to specific attributes in a business document using specific processing rules. The use case begins when you have an attribute in a document that requires special routing using processing rules. The use case ends when you have routed the document successfully using the intended processing rule.
To extract attributes from a document:
To use the extracted attribute as extended criteria in a processing rule:
Fields | Values |
---|---|
Attribute | Select the attribute that you want the processing rule to match with the inbound document. |
Data type | Select the data type of the value associated with the attribute. |
Operator | Select the match criteria. The operator you can use depends on the data type of the attribute. |
Value | Specify the value to which the attribute must be a match. |
See the Course of transaction to check if the inbound document was processed by the correct processing rule after matching the extended criteria.
webMethods.io B2B facilitates cross-border eProcurement through the Peppol network, which enables trading partners to exchange electronic documents using a set of artifacts and specifications through the AS4 channel.
Peppol Access Points connects users to the Peppol network and enable the exchange of electronic documents according to the Peppol specifications. The sender and receiver selects their preferred access point provider to connect with all existing Peppol participants on the network.
To transmit electronic documents successfully from a sender to the intended recipient, it is necessary for all Peppol access points to know each other. This is facilitated by a centralized service, called the Service Metadata Locator (SML), which is maintained by Peppol. The Peppol SML determines the appropriate Service Metadata Publisher (SMP) to utilize to get the necessary delivery details for any Peppol participant.
Ensure you set up the following assets in webMethods.io B2B for the related Flow services to work in webMethods.io Integration:
Enterprise profile:
End-user profile:
The transactions appears on the Transactions page of webMethods.io B2B when the Flow services in webMethods.io Integration is run.
See the Course of transaction to check if the transactions are recorded in the Transactions page of webMethods.io B2B as per the partner-specific TPA.
Copyright © 2019-2024 Software AG, Darmstadt, Germany and/or Software AG USA Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors. Imprint | Privacy policy |