Understanding webMethods Trading Networks

Edit online

webMethods Trading Networks

Edit online

A trading network is a group of organizations that have agreed to exchange business documents. Participants might include strategic partners, buyers, suppliers, and marketplaces (for example, Ariba Network), and are referred to as trading partners. Business documents typically include purchase orders, order statuses, purchase order acknowledgements, invoices, and other domain-specific business documents.

webMethods Trading Networks enables your corporation to connect to other organizations to form a business-to-business (B2B) trading network. Trading Networks is a format-neutral, business-document gateway that can recognize and process documents that flow between distributed trading partners. Through Trading Networks, you can exchange business documents with the partners in your network to relay production information. The business documents can be in any format that is recognized by two partners, such as XML and flat file.

Trading Networks is also the base through which webMethods products support numerous eBusiness Standards (eStandards) such as RosettaNet, EDI, ebXML Messaging Service, SWIFT, FIX, and CIDX. webMethods eStandards Modules use features of Trading Networks to perform the processing behavior required for the eStandard supported by the module.

Trading Networks and ActiveTransfer form the primary components of the B2B solution in the webMethods suite of products. Trading Networks provides B2B capabilities such as, partner management, document management, processing rules, TPAs, transaction monitoring, and so on. ActiveTransfer has the ability to send documents to Trading Networks. By using the managed file transfer capabilities of ActiveTransfer, you can leverage the B2B capabilities of Trading Networks to manage and deliver documents to partners securely and efficiently.

Architecture

Edit online

webMethods Integration Server hosts packages that contain services and related files, and provides an environment for the orderly, efficient, and secure execution of services. By way of the WmTN package, Trading Networks Server manages the partners on your network and the exchange of documents.

My webMethods is a Web-based user interface framework that supports administration and monitoring user interfaces for webMethods products. The Trading Networks user interface in My webMethods lets you perform all Trading Networks tasks. My webMethods Server is the run-time container for functions that webMethods products make available. For example, when a user searches for a Trading Networks asset, My webMethods Server interacts with Trading Networks to perform the search and return the asset to the user.

The Trading Networks database stores all information about the trading network, such as partner information, types of documents to process, processing actions, and log activity.

The figure depicts the architecture of webMethods Trading Networks Architecture

Partners in a Trading Network

Edit online

Each of your partners has its own system that communicates with your Trading Networks system. The partner system does not have to use Trading Networks or other Software AG software. When you identify a partner to your Trading Networks system, you provide information about how to connect to and exchange documents with the partner.

The following diagram illustrates various configurations of partners in a trading network.

In this network, one partner system is an Integration Server that is not using Trading Networks. The application server and marketplace partner systems are not using any Software AG software. The partner in the center is referred to as the hub of the network. The other partners are referred to as spokes. The hub hosts the network and the spokes participate by interacting with the hub.

A Trading Networks partner does not have to be exclusively a hub or a spoke; it can be a hub of its own network and a spoke in another partner's network or it can be both, as shown in the following diagram.

Understanding the Trading Networks Terminology

Edit online

webMethods Trading Networks is a component that runs on webMethods Integration Server. Trading Networks enables your enterprise to link with other companies (buyers, suppliers, strategic partners) and marketplaces to form a business-to-business network.

The components of Trading Networks are a server and the My webMethods interface. The My webMethods interface is a web-based administration and monitoring user interface for managing your My webMethods components.

Trading Networks terminology and description are listed in the table as follows:
Term Description
Activity Log A log that Trading Networks maintains to record the activity that occurs within the Trading Networks system. Trading Networks records entries, for example, when you manage trading partner information, when it processes documents, and when you perform administrative tasks.
Business Process A multi-step interaction among participating systems, people, and trading partners. A business process can be fully automated (involve only interaction among computer systems) or include varying degrees of human interaction (for example, review and approval steps). It can be either brief or long-running.
Custom Attribute A document attribute that you define to identify information within a document that is of interest to you.
Deliver Sending an outbound document from Trading Networks to the trading partner that is the receiver of the document.
Delivery Method A method for delivering a document to a trading partner. For example HTTP, HTTPS, FTP, FTPS, e-mail (SMTP), SFTP, Web Service. Trading Networks supports, immediate delivery methods, scheduled delivery methods, receiver's preferred delivery method, and queue for polling.
Delivery Task A task that Trading Networks establishes to keep track of the attempts to re-deliver a document when it is using reliable delivery.
Document A business document (For example, purchase order, acknowledgement, confirmation) sent to Trading Networks. The document can be in any format (XML, EDI, etc.) Trading Networks provides out-of-the-box support for XML and flat file documents. The webMethods EDI Module is necessary for EDI documents.
Document Attribute A Trading Networks object that defines a piece of information within a document that is of interest. For example, document attributes in a purchase order might be the purchase order number, the account number of the purchase order and the total purchase amount. Document attributes can be either a system attributes (those that are provided with Trading Networks) or custom attributes (those that you define for your enterprise).
Document ID A system attribute for an identifier in a document that is typically a unique value that distinguishes a document from other versions of the same document.
Endpoint An endpoint is one end of a communication channel. A specific call or transaction can be made on an API by an application through an API endpoint.
Enterprise Partner The partner that hosts the trading network. On your Trading Networks system, this would typically be your corporation. (Also known as the hub, local partner, or sponsor.)
External ID The value of the external ID type within a document. For example, if the external ID type is a D-U-N-S number, the external ID is the actual value of the D-U-N-S number.
Flat File Any file or document that has a format that is non-describing, that is, a document that does not contain metadata. A flat file document presents hierarchical data in a record-based storage format, which unlike XML, does not embed structural information within the data.
Immediate Delivery Method A delivery method where Trading Networks attempts to immediately deliver a document directly to the receiving partner. You can create immediate delivery methods using all the supported delivery methods.
Local Partner The enterprise partner that hosts Trading Networks. (Also known as the enterprise partner, hub or sponsor.)
Private Queue A scheduled delivery queue that you define to schedule the delivery of documents that are aimed at one specific trading partner. You define a private queue in the profile of the partner to receive the documents.
Processing Rule A Trading Networks object that contains a set of actions that determine how Trading Networks is to process an inbound document and criteria that indicates when to select a processing rule for an incoming document.
Profile A Trading Networks object that contains a summary of information about a corporation that is part of a trading network. A profile contains standard fields that Trading Networks provides and extended fields that are site-defined.
Public Queue A scheduled delivery queue that you define to schedule the delivery of documents that are aimed at multiple trading partners.
Reliable Delivery A feature of Trading Networks where Trading Networks attempts to re-deliver a document to a trading partner one or more times if previous attempts to deliver the document fails. For an immediate delivery method, Trading Networks automatically uses reliable delivery when the pre-processing action Save Document to Database indicates that Trading Networks is to save the document content to its database. For a scheduled delivery method, Trading Networks always uses reliable delivery.
Scheduled Delivery Method A delivery method where Trading Networks batches multiple documents in a scheduled delivery queue. The documents in the queue are acted on at scheduled times to deliver them.
Trading Networks Document Type A Trading Networks object that defines how Trading Networks is to recognize a document and initial actions to take on a recognized document. Trading Networks recognizes the document by using identification information in the TN document type. The actions specified in a TN document type indicate the document attributes that Trading Networks is to extract from the document (including information about XML namespaces the documents might use) and specify options for pre-processing the document (which include verification, validation, and whether to save the document attributes, document content, and log entries for the document to the database).
Trading Partner Agreement A Trading Networks object that you can use to tailor how documents are exchanged between two trading partners.
Trading Partner A trading partner may be an organization in your trading network, for example, a strategic partner, marketplaces, buyer, or supplier. Each trading partner requires a profile. You can exchange business documents with the trading partners in your network to relay mission critical production information.
Transaction The documents that have passed through Trading Networks.
Unknown Document A document that does not match any Trading Networks document type.
Unknown Partner A trading partner (sender or receiver) of a document is considered unknown if Trading Networks is unable to determine the sender or receiver; that is match the sender or receiver to a profile in the Trading Networks system.
User Status A system attribute that contains a status that a user can associate with a document. For example, "Needs Approval".

Asset Definition

Edit online

When Trading Networks receives a document, it performs run-time processing. You define this processing by designing Trading Networks assets as listed in the following table:

Assets Description
Document attributes Identify the pieces of document content you need to process documents. For example, you might be interested in document senders and receivers, or the total amounts of purchase orders.
Document types Define document types for documents you and your trading partners will exchange. Document types are definitions that represent particular categories of documents (for example, XML or flat file). The document type can represent an industry standard, such as a cXML Purchase Order, FIXML Quote Request, or Biztalk Envelope, or a custom standard, such as a purchase order format that you and a partner have agreed on.

Document types can also specify actions to perform for documents, such as saving documents to the Trading Networks database.

Processing rules Specify actions to perform for documents, such as delivering documents to partners.
Profiles Identify your corporation and the corporations of the partners in your trading network, and specify how to connect to each other and exchange documents.
Trading Partner Agreements (TPAs) Specify transaction-dependent information that is specific to a group of transactions between two trading partners. A transaction is the passage of a document through Trading Networks.
Note: You define assets differently for large documents. For details, see Large Document Handling.

Document Attributes

Edit online

Trading Networks supports two types of document attributes: system attributes and custom attributes. Trading Networks defines the system attributes as listed in the following table:

System Attribute Description
SenderID Identifier for the sender of a document.
ReceiverID Identifier for the receiver of a document.
DocumentID Unique identifier for a document.
UserStatus Status that you or a partner assign to a document (for example, Needs Approval).
GroupID Identifier that associates a document with other documents in a group. Grouping documents is helpful for end users doing document searches.
ConversationID Identifier that associates a document with other documents that are processed by a business process (also called a conversation of documents). For information about business processes, see Business Process Definition. This identifier is only present if you are using BPM. You need to extract it from the document and add it to the document type. The transaction with the ConversationID then gets attached to the business processes.
SignedBody For XML documents, data that was digitally signed to create the digital signature for the document.
Signature For XML documents, digital signature of the document.

You define custom document attributes. For example, if you are interested in PO numbers and total order mounts, you might define PO_Number and Total_Order_Amount custom attributes.

You tell Trading Networks to extract document attributes from documents you receive for these reasons:

  • To use extracted attributes as a criterion for using a particular processing rule. For example, if you want to use one processing rule if the sender is Partner A and another processing rule if the sender is Partner B, you would extract the system attribute SenderID. Or if you want to use a particular processing rule when the receiver is Partner C and the total order amount is greater than $10,000, you would extract the system attribute ReceiverID and the custom attribute Total_Order_Amount.
  • To perform certain processing actions that require extracted attributes. For example, if you want to deliver a document to the receiver partner, you would extract the system attribute ReceiverID. If you want to verify the digital signature of an XML document, you would extract the system attributes SignedBody and Signature.
  • To search for documents in My webMethods based on extracted attributes. For example, if you want to be able to find documents that were sent by Partner A for which the total order amount is greater than $10,000, you would extract the system attribute SenderID and the custom attribute Total_Order_Amount.
  • If you BAM-enable Trading Networks and you want to pass extracted attributes to Optimize for B2B for analysis and monitoring. For example, if you want to generate a report on the purchase order quantity for a particular sender from a particular receiver, you would extract the custom attribute PO_Quantity and the system attributes SenderID and ReceiverID.

Document Types

Edit online

You can define document types for XML and flat file documents. For example, you might define document types for documents that represent purchase orders or acknowledgements. For XML documents, you define document types for variations of documents; for example, you might define purchase orders in cXML, OAG, and CBL.

A document type specifies criteria that an inbound document must meet to match the document type, document attributes to extract from documents that match, and processing to perform for those documents. You define exactly one document type for each document you expect to receive or send.

If webMethods Module for EDI is installed on the same Integration Server that hosts Trading Networks, you can also define document types for EDI documents. For instructions, see webMethods Module for EDI Installation and User’s Guide .

The explanation of document types in this section mentions the pipeline. The pipeline is an Integration Server data structure in which input and output values from services 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.

XML Document Types

Edit online

The XML document type definitions are listed in the table as follows:

Definition Description
Document recognition criteria Content that an inbound XML document must have to be a match for the XML document type. You can specify one or more of the following:
  • Root tag the document must have.
  • System or public identifier from the DOCTYPE declaration the document must have.
  • Nodes and, optionally, values the document must have. You define XML Query Language (XQL) queries that Trading Networks executes to find the nodes and values.
  • Pipeline variables (that is, variables inserted into the pipeline by the service that sends the document to Trading Networks) and, optionally, values the variables must have.
Attribute extraction System and custom attributes to extract from the document. You define XQL queries that Trading Networks executes to extract the attributes. You can also specify transformations for extracted attributes; for example, you might want to transform an extracted string value into all uppercase characters.
Pre-processing actions

A document type can specify one or more of these actions:

  • Format as IS Document Type action, to transform the document into an IS document that can be parsed into an IData object. An IData object is a collection of name/value pairs on which services can operate. An IData object can contain any number of elements of any valid Java objects, including additional IData objects.
  • Verify Digital Signature action, to make sure the signed body of the document arrived unchanged and the sender is who it claims to be. Trading Networks checks the sender by matching the certificate from the digital signature to the certificate in the partner’s profile.
  • Validate Structure action, to validate the structure of the document against a specified schema.
  • Check for Duplicate Document action, to check whether Trading Networks has already received the document. Trading Networks saves the results of the check to the pipeline, so you can use the results in the Save Document to Database pre-processing action (below) to save only unique documents, and in processing rule actions.
  • Save Document to Database, to save the document to the Trading Networks database. For example, you save documents to the database when you want to make multiple attempts to deliver documents to partners.
  • Indicate whether to use a processing rule to further process the document. You might not want to use a processing rule if you want to simply persist the document to the Trading Networks database, or to process the document using a business process instead of a processing rule. For information about business processes, see Business Process Definition.

Flat File Document Types

Edit online

Flat file documents present complex hierarchical data in a record-based storage format which, unlike XML, does not embed structural information within the data. The Trading Networks definition of a flat file is any file or document whose format is non-describing; that is, a document that does not contain metadata. In other words, flat file data is externalized as a set of records (list of records containing fields and composites) without any structural information. Since the records are not structured in the document, the application receiving the flat file must know the structure of the flat file to read its content.

Since Trading Networks does not know the structure of a flat file document, it cannot extract values for attributes directly from documents. The entry points for flat files into Trading Networks, therefore, are document gateway services; that is, your trading partners send their flat files to document gateway services rather than directly to Trading Networks. A document gateway service does the following:

  • Reads an inbound flat file document
  • Places output variables such as the flat file document type for the document; the processing rule for the document; system document attributes such as SenderID, ReceiverID, and UserStatus; and custom attributes in the pipeline
  • Passes control to Trading Networks

A flat file document type definitions are listed in the table as follows:

Definition Description
Document recognition criteria Content that an inbound flat file document must have to be a match for the document type. You can specify any of the variables the document gateway service placed in the pipeline, such as the name of the flat file document type to use; the SenderID, ReceiverID, or UserStatus system attributes; or custom attributes.
Attribute extraction System and custom attributes to extract from the document. You can also specify transformations for extracted attributes; for example, you might want to transform an extracted string value into all uppercase characters.
Pre-processing actions Same as for XML documents, except that the Format as IS Document Type action is not available for flat file documents (see XML Document Types).

Processing Rules

Edit online

A processing rule specifies criteria that a document must meet to match the rule, and processing to perform for the documents that match. The criteria is listed in the table as follows:

Definition Description
Matching criteria Content that a document must have to match the processing rule. You can specify the following as criteria:
  • Sender and receiver the document must have
  • Document type for the document
  • User status the document must have (for example, Needs Approval)
  • Whether errors were or were not encountered during document recognition or attribute extraction
  • Custom attributes the document must have (for example, Total_Order_Amount custom attribute value greater than $10,000)
Pre-processing actions The pre-processing actions you can define in a processing rule are the same as those you can define for document types (see XML Document Types). The difference is that you must specify what to do for each action. A processing rule can specify to:
  • Perform the action that is defined in the document type.
  • Perform the action that you define in the rule.
  • Never perform the action at all.
Processing actions

A document type can specify one or more of these actions:

  • Execute a Service action, to execute a custom service. For example, you could execute a service to send the document to a back-end system for processing or to update data in an internal system with extracted attributes. You can use data that is in the pipeline in the service; for example, you could perform the Check for Duplicate Document pre-processing action and then execute one service if the document is a duplicate and another service if the document is unique. Trading Networks places the service results in the pipeline so you can use them in output templates or other processing actions.
  • Alert Email Message action, to send a message to a contact in the sender’s or receiver’s profile, the webMethods system administrator, or a specified email address when document processing is complete. For example, if the document is a purchase order, you could send a message to alert the person who approves purchase orders. You can include pipeline data in the message (for example, the document type for the document).
  • Change User Status, to assign a user status to the document for use when searching for documents or generating reports. For example, if the document is a purchase order, you could set the document’s user status to Needs Approval. The person who approves purchase orders can search for documents whose user status is NeedsApproval. The user status is assigned to the User Status system attribute.
  • Deliver Document By action, to deliver the document to the receiving partner using a specified delivery method.
  • Respond action, to send a message back to the document sender (for example, an acknowledgement for a purchase order). You can include data from the pipeline in the message. For example, you could have the Execute a Service action asynchronously invoke a service that performs the appropriate processing for the purchase order, then return confirmation that the purchase order was received and processed. You could then have the Respond With action return an acknowledgement that indicates that the purchase order was received.

Profiles

Edit online

You add partners to your trading network by defining profiles. A profile contains information about a corporation that is a trading partner in your network. You define a profile for your corporation (called the Enterprise profile), and for each of the other corporations that are trading partners in your network.

Overview of Creating Partner Profiles

Edit online
About this task

Trading Networks administrators can create partner profiles in two ways:

  • Partner Administration page in My webMethods. The administrator obtains details about the partner from the business user who identified the partner as a prospective trading partner. The administrator then enters that information on various My webMethods pages on behalf of the partner. For information about creating a profile using this method, see Creating Profiles.
Trading Networks provides standard fields for profiles. You supply these types of information in standard fields:
  • General information about the corporation, such as corporation name, address, and contacts
  • Information about how to deliver documents to the corporation
  • Certificate information for digital signing of documents, verifying digital signatures, encrypting and decrypting documents

You define external ID types for the types of identification used in documents that are exchanged in your network, and then specify the actual external IDs in profiles. For example, you could define the external ID type DUNS, and then in profiles, you could specify external IDs that contain the actual values of the D-U-N-S numbers in documents. Trading Networks uses external IDs to identify the sending and receiving partners within a document. For example, Trading Networks compares the value of the D-U-N-S number in a document to the external IDs in profiles. If it finds a profile with an external ID that matches the D-U-N-S number, it determines that the sender of the document is the partner with that profile. You can specify an unlimited number of external ID types. Each profile must include at least one external ID.

If you want to maintain additional information about your partners, you can define custom fields, called extended fields. For example, you might want to define extended fields for preferred shipping method, cost centers, or customer codes.

By default, many standard profile fields are required. When a profile field is required, all profiles on your system must have a value for it. You can make standard fields required or not required, and you can make extended profile fields required or not required.

You can associate profiles with partner groups. For example, you can create a partner group named Buyers to associate all of your partners who are buyers in your trading network. A partner can belong to more than one partner group. You can use partner groups in the sender or receiver criterion when matching processing rules to documents.

Overview of the Partner Onboarding Process

Edit online
About this task

The partner onboarding process can help you automate the creation of partner profiles and trading partner agreements (TPAs). The administrator obtains details about the partner either from the business user who identified the partner as a prospective trading partner (by way of a comma-separated values, or .csv, file) or directly from the partner (by way of a questionnaire). Trading Networks automatically creates the partner’s profile using the details provided in the spreadsheet or questionnaire.

Following is a high-level overview of the partner onboarding process:
  1. The administrator uploads a spreadsheet into My webMethods that contains basic information about one or more partners. At a minimum, the spreadsheet can contain the partner’s name and email address. The spreadsheet can also contain other standard profile, TPA, and document type information, such as partner address, preferred delivery method, external ID, and profile extended fields. The administrator can download the sample template provided, enter the information, save it, and upload the file.
  2. Trading Networks creates the beginnings of a partner profile and TPA using the information in the spreadsheet. In My webMethods, Trading Networks sets the status of the partner to New (Pending Partners page) and the status of the TPA to Agreed (Trading Partner Agreements page).
  3. If additional details are needed from the partner (for example, if the spreadsheet contained only the partner name and email address), the administrator does the following:
    1. Creates a questionnaire template that identifies the additional information needed
    2. Assigns the template to the partner
    3. Configures settings for an invitation to be emailed to the partner
    4. Grants the partner permission to access the partner onboarding pages in My webMethods
    5. Sends the invitation email to the partner requesting him or her to log in to My webMethods to complete the questionnaire
  4. Trading Networks sets the partner’s status to Invited.
  5. The partner completes the questionnaire. Trading Networks sets the partner’s status to Responded.
    Note: If the partner does not complete the questionnaire within a configured time limit, Trading Networks sets the partner’s status to Expired. The administrator can restart the onboarding process for that partner by re-inviting the partner.
  6. The administrator checks the details that the partner has submitted. If they are complete and in order, the administrator approves the partner. If the details are not in order, the administrator resends the questionnaire for the partner to enter again.
  7. If the partner enters the questionnaire correctly this time, the administrator approves the partner. If not, the administrator rejects the partner and Trading Networks sets the partner’s status to Rejected.
  8. If the partner is approved, Trading Networks adds the information from the questionnaire to the partner’s profile and TPA. The profile is changed from Pending to Approved.

For procedures related to the partner onboarding process, see Onboarding New Partners.

TPAs

Edit online

You can define trading partner agreements (TPAs) for pairs of partners. Each TPA contains specific information about how documents should be exchanged between two trading partners, as follows:

  • The partner that represents the sender of the documents.
  • The partner that represents the receiver of the documents.
  • An agreement ID that identifies the type of TPA (for example, TPAs for the webMethods Module for EDI use the agreement ID EDITPA).
  • The TPA data that contains the application-specific variables to use to tailor the processing of documents exchanged between the sender and receiver. You specify this data by defining an IS document type. An IS document type is an element in the Integration Server namespace that contains a set of fields that define the structure and type of data in an IS document, or IData object. For example, the webMethods Module for EDI ships with an IS document type (the wm.b2b.editn.TPA:EDITPA IS document type) to use for TPAs for partners exchanging EDI documents. This IS document type contains a set of variables that are used for processing EDI documents.
  • Optionally, an initialization service you supply to initialize the TPA data (for example, the webMethods Module for EDI supplies an initialization service to set the TPA values to its default values).
  • Optionally, a validation service you supply to validate the data added to the IS document for the TPA.
  • Optionally, an export service you supply to export the TPA data to an industry-standard format.

Trading Networks does not use TPAs for its own processing; rather, the data you specify in the TPA are available for your own use. For example, you can access the TPA information from services that are executed by a processing rule. Access to this information allows you to build a document exchange application that uses the TPA to tailor the exchange of documents between partners. Other webMethods products take advantage of the TPA feature in Trading Networks. For example, the webMethods ebXML Module uses the TPA feature to support ebXML Collaboration Protocol Agreements (CPAs).

The set of parameters can be different for different types of TPAs. For example, you might use TPAs for partners that exchange documents using ebXML that contain the parameters defined by the webMethods ebXML Module. Other partners might exchange documents using EDI, and for those partners you create TPAs that contain parameters defined by the webMethods Module for EDI.

The type of information a TPA contains is different than the type of information that Trading Networks maintains in profiles. A profile contains information about the partner that does not vary with each document being exchanged, such as company name and address, certificate information, delivery protocol parameters, and external IDs. TPAs are intended to contain transaction-dependent information (for example, configuration information to support specific types of documents being exchanged) that are specific to a group of transactions between the two trading partners (for example, digital signature or encryption to a message). TPAs augments profiles and offer a flexible way to process and manage the documents exchanged between two trading partners.

When you define a TPA, you set the agreement status. This status indicates the status of the TPA agreement between the receiver and sender. The status can be proposed, agreed, or disabled. webMethods products that use the TPA feature recognize these statuses. For example, if webMethods ebXML Module tries to use a TPA whose status is disabled, it acts as if there is no TPA. If you create an application that uses TPAs, it should check and honor the disabled status.

Business Process Definition

Edit online

For some documents, you might require multi-step processing that involves interaction among systems, people, and trading partners. An example of such a processing is the fulfillment of a purchase order that includes a purchase order document, human interaction to determine whether to approve the purchase order, and either an order acknowledgement (ACK) document or an order negative acknowledgement (NACK) document. For such processing, you can define a business process. You can use a business process instead of or in addition to a processing rule.

You define business processes in Software AG Designer. Designer generates the run-time elements needed to run the business processes (for example, triggers and flow services) in Integration Server. The Process Engine, which runs on Integration Server, manages the execution of business processes.

To handle documents sent by Trading Networks, you must define the business process to handle a conversation of related documents that all contain the same conversation ID. The conversation ID is the Trading Networks ConversationID system attribute. When you want to process documents using a business process, the document types for the document must tell Trading Networks to extract this attribute. When this attribute has been extracted, Trading Networks knows to pass the document to the Process Engine after Trading Networks processing is complete.

For complete information on business processes, see the webMethods BPM documentation.

Document Delivery

Edit online

To deliver a document to a receiving partner, you create a processing rule for the document type, and you define the Deliver Document By processing action in the processing rule. Based on the action, you identify the type of delivery to use.

The following table describes the delivery types:
Delivery Type Description
Immediate delivery Delivers the document directly to the receiving partner. Trading Networks tries to deliver the document only once unless you use reliable delivery to make repeated attempts.
Scheduled delivery Places the document in a queue you define and delivers the document to the receiving partner at scheduled times. You use scheduled delivery when it is more efficient to deliver a batch of documents than to deliver each document as it arrives. For example, if you want to deliver documents through FTP, you might use scheduled delivery so you can open a connection, deliver the batch of documents, and then close the connection, rather than use immediate delivery, which requires you to open and close a connection for each document. Trading Networks tries to deliver the document only once unless you use reliable delivery to make repeated attempts.
Receiver's Preferred Protocol A preferred protocol for receiving documents is set up when a partner profile is created.
Queue for polling Places the document in the Trading Networks-provided queue. When a partner polls for documents, Trading Networks delivers all documents in the queue for which the partner is the receiver. Queue for polling is the default delivery method. If you do not set up immediate or scheduled delivery for a partner, Trading Networks uses queue for polling for that partner.

Immediate Delivery

Edit online

Immediate delivery uses immediate delivery methods, immediate delivery services, and, if you use reliable delivery, delivery tasks. An immediate delivery method invokes an immediate delivery service that delivers a single document to the receiving partner. A delivery task is a task Trading Networks creates to keep track of its attempts to redeliver a document when you are using reliable delivery. The options for immediate delivery are as follows:

  • Trading Networks provides standard FTP, FTPS, HTTP, HTTPS, SFTP, SMTP, and Web service delivery methods. You can create custom immediate delivery methods from these methods; you create the custom method in one profile, and then you can select the method in other profiles. When you create a custom method from a standard method, Trading Networks automatically creates the corresponding immediate delivery service. If that service does not meet your needs, you can create a custom service to replace it.
  • Trading Networks provides built-in immediate delivery methods for primary and secondary email, FTP, FTPS, SFTP, HTTP, and HTTPS, and provides the corresponding built-in delivery services. If the services do not meet your needs, you can create custom services to replace them.
  • You can create custom immediate delivery services. For example, you might want to create a custom service that delivers a message into a message queuing system. After you create a custom service, you register it with Trading Networks, and Trading Networks automatically creates the corresponding immediate delivery method.
  • Trading Networks provides ActiveTransfer as a delivery method. By using the managed file transfer capabilities of ActiveTransfer, you can leverage the B2B capabilities of Trading Networks to manage and deliver documents to partners securely and efficiently as follows:
    • Manage partners in Trading Networks.
    • Set up complex endpoints (Virtual Folder System or VFS) for partners in ActiveTransfer.
    • Configure Trading Networks as a central partner management to use ActiveTransfer Server depending on whether ActiveTransfer is installed on a local, remote, or clustered environment, as the preferred document delivery method. For more information, see Configuring Alias for ActiveTransfer on Remote Server.
    • Select an ActiveTransfer VFS path for the partners. Using the VFSPath, senderPartnerID, receiverPartnerID, and VFSID parameters, ActiveTransfer sends the BizDocument to the partners.
    • View the status of the document delivery and the delivery details from ActiveTransfer on the Transactions and Activity Log pages.
    Note: Trading Networks does not support the delivery of large documents to ActiveTransfer on a remote Integration Server instance. For more information about handling large documents in Trading Networks, see Large Document Handling.

To use immediate delivery for a partner, define one or more immediate delivery methods in the partner’s profile. You can then specify the method to use for a document on the Deliver Document By action.

You can designate one immediate delivery method as the partner’s preferred protocol, and specify using the partner’s preferred protocol for a document on the Deliver Document By action. The preferred protocol option is primarily for use with webMethods eStandards Modules.

To use reliable delivery, you specify the Save Document to Database pre-processing action on the processing rule. In the receiving partner's profile, you specify the number of times to try to deliver a document to the partner and the amount of time to wait between attempts. If Trading Networks retries the maximum number of times and delivery is unsuccessful, it changes the delivery task status to FAILED. If you correct the problem, you can restart the task and Trading Networks will start trying to deliver the document again.

Scheduled Delivery

Edit online

Scheduled delivery for a partner uses a scheduled delivery queue, a scheduled delivery service, a delivery schedule, and delivery tasks.

There are two types of scheduled delivery queues:

  • Private queues, each with a delivery schedule and delivery service you define. Each private queue delivers documents to only one partner.
  • Public queues, each with its own delivery schedule and delivery service you define. Each public queue can deliver documents to multiple partners.

To use scheduled delivery for a partner, you indicate which queue to use in the partner’s profile; that is, you specify the partner’s private queue or one of the public queues. You then specify the queue to use for a document on the Deliver Document By processing action.

Trading Networks automatically uses reliable delivery with scheduled delivery.Trading Networks creates a delivery task that invokes the scheduled delivery service and places the task in the specified queue, and that keeps track of Trading Networks’s attempts to redeliver the document.

A scheduled delivery service delivers a batch of documents to the receiving partner. You can associate the same scheduled delivery service with multiple queues. The options for scheduled delivery services are as follows:

  • Trading Networks provides one built-in scheduled delivery service that uses FTP to deliver documents to a single destination. The service opens a connection, delivers all documents, and then closes the connection.
  • You can create scheduled delivery services and register them with Trading Networks.

At the times the queue schedule indicates, Trading Networks invokes the scheduled delivery service to deliver the documents in the queue. The service acts on all delivery tasks in the queue whose status is QUEUED. These QUEUED delivery tasks include all delivery tasks that are in the queue when the service is invoked and any new tasks that are added to the queue before the delivery service ends. The scheduled delivery service tries to deliver the document to the receiving partner and indicates whether the delivery was successful or not. The status of the delivery task is updated accordingly. If a document cannot be delivered, Trading Networks leaves the delivery task with the QUEUED status so the scheduled delivery service will to try to deliver the document again at the next scheduled time.

Trading Networks automatically uses reliable delivery with scheduled delivery, but you must specify the Save Document to Database pre-processing action on the processing rule. In the receiving partner's profile, you specify the number of times to try to redeliver a document to the partner. If Trading Networks retries the maximum number of times and delivery is unsuccessful, it changes the task status to FAILED.

Queue Documents for Polling

Edit online

Trading Networks uses queue for polling in these cases:

  • When you set the Deliver Document By processing action for a document to queue for polling.
  • When you set the Deliver Document By processing action for a document to Receiver’s Preferred Protocol, and the receiving partner’s preferred protocol is queue for polling.
  • When it cannot find sufficient delivery information in the receiving partner's profile (for example, if the Deliver Document By processing action indicates using an immediate delivery method, but the profile does not contain delivery information for that method).

When using queue for polling, Trading Networks saves the document to its database and sets the document’s processing status to POLLABLE. A receiving partner looks in your profile on its system to find the polling method to use and how often to poll. The receiving partner then polls for its documents, and your Trading Networks delivers them. The receiving partner returns a status for each document that indicates whether the document was accepted or accepted with errors. Your Trading Networks updates the processing status of the document on your Trading Networks, setting it to ACCEPTED or ACCEPTED W/ ERRORS.

Document Processing

Edit online
  1. A partner sends a document, as follows:
    • The partner sends an XML document to the Trading Networks wm.tn:receive service. The service reads the document into the pipeline. If coded to do so, the service places the name of the document type and processing rule to use for the document on variables in the pipeline.
    • The partner sends a flat file document to a document gateway service. The gateway service reads the document and places variables you specify (for example, SenderID, ReceiverID, DocumentID, and ConversationID) in the pipeline. If coded to do so, the gateway service places the name of the document type and processing rule to use for the document on variables in the pipeline, and places specified custom document attributes and their values in the pipeline. The gateway service then invokes the wm.tn:receive service.
  2. If Trading Networks does not find a document type name in the pipeline, it performs document recognition; that is, it compares the XML document to the criteria specified in enabled XML document types, or the flat file document to the criteria specified in enabled flat file document types. When it finds a match, Trading Networks creates a BizDocEnvelope from the document and places the BizDocEnvelope in the bizdoc variable in the pipeline. It then extracts the document attributes that are specified in the matching document type from the pipeline and adds them to the BizDocEnvelope, along with additional information required to route and process the document. The BizDocEnvelope represents a routeable Trading Networks transaction and conforms to the wm.tn.rec:BizDocEnvelope. The bizdoc variable adheres to the wm.tn.rec:BizDocEnvelope IS document type and is an instance of com.wm.app.tn.doc.BizDocEnvelope.

    Trading Networks also places the sender and receiver variables in the pipeline. These variables contain the partners identified as the sender and receiver, respectively, in the document. The variables adhere to the wm.tn.rec:ProfileSummary IS document type and are instances of com.wm.app.tn.profile.ProfileSummary. To view the IS document type, open Software AG Designer and look in the WmTN package wm.tn.rec folder.

  3. The next action depends on whether the pipeline contains a processing rule name and what the document type specifies, as follows:
    • If the document type specifies the use of a processing rule, Trading Networks continues with step 4.

    • If the pipeline specifies a processing rule name, Trading Networks skips to step 5.

    • If the pipeline does not contain a processing rule name, and the document type specifies to not use a processing rule, Trading Networks performs any pre-processing actions that are specified in the document type in the order they are listed in Document Types. Trading Networks then skips to step 7.
  4. Trading Networks compares the document to the criteria specified in all enabled processing rules.
    The following table describes the criteria and the action:
    Criteria Trading Networks Action
    Sender, receiver, or both Compares to the SenderID and ReceiverID system attributes in the document. If Trading Networks matches these SenderID and ReceiverID system attributes to a partner profile, it uses the corporation name and unit name specified in the profile as the name of the sender, the receiver, or both. Trading Networks compares the name of the partner to the partner or partners specified in the processing rule.
    Document type Compares to the document type for the document.
    User status Compares to the UserStatus system attribute for the document.
    Occurrence or non-occurrence of errors during document recognition Checks for errors in the pipeline.
    Custom attributes Compares to the attributes it extracted from the document.
  5. Trading Networks performs the pre-processing actions specified by the matching processing rule in the order they are listed in Processing Rules.
  6. Trading Networks performs the processing actions specified in the processing rule in the order they are listed in the following table:
    Criteria Trading Networks Action
    Execute a Service Processing depends on how you invoke the action, as follows:
    • Synchronous: Invokes the service once, waits for the service to complete, and places the results in the pipeline. You can use the service results in output templates or other processing actions. If you do not use the Respond With action, Trading Networks returns the results of the service unmodified to the client that sent the document. If you do use that action, Trading Networks returns only the message you specify.
    • Asynchronous: Invokes the service once and does not place the results in the pipeline. If there are subsequent processing actions, Trading Networks immediately performs them; if there are not, it returns to the caller that sent the document for processing. If you do not use the Respond With action, Trading Networks returns no information to the caller. If you do use that action, Trading Networks returns the message you specify.
    • Service execution task: Invokes the service and uses reliable execution to retry the service if it fails. Trading Networks creates a service execution task to keep track of its attempts to execute the service. If Trading Networks retries the maximum number of times and the service is still unsuccessful, it updates the task status to FAILED. The processing and information returned to the caller are the same as for Asynchronous.
    Send an Alert Email Sends the specified email to the specified person.
    Change User Status Assigns the specified user status to the document. For an example of using user status criteria during processing, see Example of User Status in Document Processing.
    Deliver Document By Delivers the document to the receiver that is identified in the document using the delivery method you specified in the processing rule.
    Respond with Returns the specified message to the caller that sent the document to be processed.
  7. If you extracted the ConversationID system attribute from the document, Trading Networks passes the document to the Process Engine for processing by a business process. If the Process Engine finds a running business process that uses the document’s conversation ID, it passes the document to the running process. If Process Engine does not find such a running business process, it searches for a process model whose first step waits for the document and starts a new instance of the process model. The Process Engine logs the status of business processes so you can view and monitor their progress.

Error Logging

Edit online

Document Recognition Errors

Edit online
  • To determine the document type to use for an XML document, Trading Networks looks at all enabled XML document types. To determine the document type to use for a flat file document, Trading Networks looks at all enabled flat file document types. Each document that passes through your system should match exactly one document type. If a document does not match any document type, or matches more than one document type, Trading Networks considers it an unknown document type. When Trading Networks encounters an unknown document type, it:
    • Cannot extract any attribute information from the document, since document types identify the attribute information to extract.
    • Tries to process the document using a processing rule that acts on unknown document types, if you define one.
    • For documents that match more than one document type, Trading Networks logs a message that identifies those document types to the Trading Networks activity log.
  • Trading Networks flags the following during document recognition:
    • A sender or receiver error if the external ID of the sender or receiver in the document does not match the value of the external ID in any partner profile.
    • An attribute error if Trading Networks cannot extract an attribute that is marked as required in the document type.
    • For an XML document, a sender or receiver error if the XQL query in the document type cannot find the SenderID or ReceiverID system attribute in the document.
    • For an XML document, a general error if an XQL query in the document type fails. For example, a general error occurs when the document is identified as an XML document but contains invalid XML or is actually another format, such as plain text or EDI.

Document Processing Errors

Edit online
  • When a partner tries to send documents to a partner whose profile is disabled, Trading Networks logs an error message to the activity log, sets the processing status of the document to ABORTED, and sends an email message to the Trading Networksadministrator. If the document was sent using HTTP, Trading Networks also responds to the sender with an HTTP 403 message.
  • If Trading Networks encounters an error while performing a pre-processing action, it records the information to its activity log and continues to perform the other pre-processing actions. The same is true for processing actions.
  • If you used the Check for Duplicate Document pre-processing action, Trading Networks might not be able to determine whether a document is unique if:
    • It could not match the document to a document type.
    • It previously received the same document but did not save it to the database.
    • It previously received the same document and saved it to the database, but:
      • The document type did not indicate to extract the DocumentID, SenderID, and ReceiverID system attributes.
      • For a flat file, the document gateway service did not place the DocumentID, SenderID, and ReceiverID system attributes in the pipeline.
  • If you used the Deliver Document By processing action, Trading Networks might require additional information from the receiving partner's profile before it can deliver the document. For example, for immediately delivery methods, Trading Networks must look in the profile for the host name and port for the receiving partner’s system. If Trading Networks cannot determine the required delivery information (for example, because the receiving partner’s profile is disabled), it logs the error to the activity and queues the document for polling.
  • If a document was sent by one of your partners but Trading Networks cannot determine the sender, Trading Networks considers the sender an unknown partner. If you have a processing rule that processes documents that are sent by the partner, Trading Networks will not select the rule. Trading Networks cannot determine the sender in these cases:
    • The document type is unknown, so Trading Networks cannot extract any document attributes, including the sender or receiver.
    • The document type does not indicate to extract the SenderID and ReceiverID system attributes, so Trading Networks cannot determine the document sender or receiver.
    • The value of the SenderID and ReceiverID system attributes do not match the value of the external ID type of any partner defined in aTrading Networks profile.
    • In an XML document type, the XQL query cannot find the SenderID and ReceiverID system attributes in the document.

Monitoring Transactions

Edit online

An end-to-end business-to-business document exchange flow corresponds to a transaction in Trading Networks. Irrespective of the type of documents, delivery methods, trading partner agreements used, a transaction is a neutral runtime aspect of a business-to-business document exchange flow in Trading Networks. You can search, view, and monitor transactions using the simple and advanced search capabilities.

To monitor the intermediate states within a transaction at a granular level, you can define a set of user statuses and update these either using a service during the course of the transaction or add or delete user statuses through Applications > Administration > Integration > B2B > B2B Settings > Transaction Settings > User Status Configuration.

Trading Networks gives you visibility into your network to track run-time information about the documents that your Trading Networks system has sent or received, delivery and service execution tasks that have been run or started, and activity log entries relating to the server. You can use My webMethods to query run-time information that Trading Networks has saved to its database.

The following table lists the run-time information you can view, along with the My webMethods pages to use to view the information:

My webMethods Page To View
Monitoring > Integration > B2B > Transactions Information about the documents that Trading Networks has saved:
  • Attributes that have been extracted from documents
  • Content of documents that have passed through your system
  • Status of documents that Trading Networks is in the process of delivering
  • For each transaction you can view the following information:
    • Date Received
    • Document Type
    • Sender
    • Receiver
    • Processing Status
    • User Status
    • Related Documents
    • Details
    • Action
  • Any task associated with the document exchange
  • Any comments that you have recorded for a transaction

In addition to viewing this information, Trading Networks also provides features you can use to resubmit and reprocess documents.

Monitoring > Integration > B2B > Tasks The progress and status of each delivery task and service execution task. In addition to viewing this information, Trading Networks also provides features you can use stop, restart, and delete tasks.
Monitoring > Integration > B2B > Activity Log Audit information of the activity that has occurred in your Trading Networks system.

If you use the same query multiple times, you can save the query settings. When you want to use the same query again, select the saved query and run it. Queries you save in one of the user interfaces cannot be used in the other user interface on Trading Networks

Security

Edit online

Managing, Authenticating, and Authorizing Trading Networks Users

Edit online
Trading Networks manages Trading Networks users through webMethods central user management, as follows:
  • When a My webMethods user who has Trading Networks administrator authority wants to perform an action that requires execution of a service on Integration Server. The user’s My webMethods credentials are used to authenticate the user and authorize the request.
  • When a My webMethods user wants to view Trading Networks data or perform Trading Networks actions, and Trading Networks services are invoked on Integration Server. The user’s My webMethods credentials are used to authenticate the user and authorize the request.
  • When a Trading Networks partner sends a document to Trading Networks, and a Trading Networks service is invoked. The partner can invoke the service using the credentials of a My webMethods user account.

When Integration Server receives a user name and password to authenticate, it first tries to authenticate the user using its own user account definitions. If the user is not defined in Integration Server user accounts, Integration Server determines whether the user account is defined in My webMethods central user management. If so, Integration Server checks whether the user supplied valid My webMethods credentials. When you use Trading Networks through My webMethods and other authentication methods such as client-side certificate authentication and third-party tools, My webMethods Server passes an authentication token to Integration Server.

To authorize a request, the Integration Server determines whether the user can access the requested Integration Server service. Access to Integration Server services is protected by Access Control Lists (ACLs). When using central user management, you can add My webMethods groups and roles that relate to Trading Networks to the Allowed list of ACLs.

Protecting Access to User Interfaces

Edit online

To prevent unauthorized access to My webMethods, a user is authenticated with a user name and password.

Trading Networks actions that you access from My webMethods are protected by role-based access. That is, to view Trading Networks data (for example, information about a delivery task) and to perform actions against that data (for example, restart a task), you must be a member of a role to which that permission has been granted. There are two aspects to role-based access:

  • Data permissions, which identify a data set of partner profiles, document types, transactions, tasks, and activity log entries along with the actions a role can perform against that Trading Networks data set. Using data-level security, you can grant roles the permissions to perform such actions as viewing, editing, or creating profiles.
  • General functional permissions, which grant a role the permission to perform Trading Networks actions against other Trading Networks data. Using general functional permissions, you can grant roles the permissions to perform such tasks as managing public queues or partner groups, or deleting partner profiles.

Protecting Partner Profile Passwords

Edit online

All passwords contained in partner profiles are securely managed by the Integration Server's Password Manager. When you create a partner profile, Trading Networks creates a handle for the password and passes both the password and its handle to the Password Manager. The Password Manager encrypts the password and stores the password and its handle in the IS repository. The Trading Networks database stores only the handle.

When you need to display or update an existing profile, Trading Networks reads the appropriate handle in its database and asks the Password Manager to return the password. The Password Manager obtains the password from the Integration Server repository, decrypts it, and returns it to Trading Networks. If the password is already cached in the Trading Networks database, this process is not necessary.

Note: Passwords used in scheduled delivery queues (public and private) are stored in the Trading Networks database in binary-encoded form (not in plain text). Trading Networks cannot encrypt passwords used in scheduled delivery queues; because trading partners are allowed to create custom scheduled delivery services, Trading Networks cannot anticipate which user-defined input variable might be a password.

Protecting Access to Trading Networks Processing

Edit online

When trading partners want to connect to your Trading Networks system (for example, to send a document for processing), access can be protected through a user account (user name/password) or x.509v3 client certificates. A partner must have partner authority to access your Trading Networks system to exchange documents. When you define a profile for a partner, you can associate one or more My webMethods or Integration Server user accounts with a profile. Your partner can use the user accounts to access your system.

When your Trading Networks system needs to connect to a partner's system (for example, to deliver a document), it can use a user account (user name/password) or x.509v3 client certificates as credentials that the partner's system uses for authentication. If your partner requires authentication using user name/password, your Trading Networks system maintains the user name and password it needs to supply when connecting to that partner in the partner's profile on your system. If a partner requires authentication using client certificates, your Integration Server system maintains the client certificate it needs to supply when connecting with that partner.

Trading Networks protects access to the wm.tn:receive service using an Integration Server Access Control List (ACL). The protection ensures that only partners with Trading Networks administrative authority or partner authority can invoke this service. To invoke the wm.tn:receive service, the client must supply the user name and password of a valid My webMethods or Integration Server user account. When using a user account with Trading Networks administrative authority, Trading Networks always accepts and processes the document. However, you will typically not grant your partners administrative authority. Instead, they have user accounts that have Trading Networks partner authority.

When you create a profile for a partner, you can associate a user account with the profile, and therefore the partner. You can associate one or more My webMethods users with the profile; Trading Networks automatically gives partner authority to the My webMethods user. When using a user account with partner authority, Trading Networks makes sure that the user that invokes the wm.tn:receive service matches the sender specified within the document being sent. Trading Networks uses the sender identified within the document to look up the sender's profile and makes sure that the profile is associated with the My webMethods or Integration Server user account that was used to send the document. If the user account is not associated with the sender's profile, Trading Networks does not process the document.

Certificates for Verifying, Signing, Encrypting, and Decrypting Documents and Authenticating Connections

Edit online

Trading Networks certificate sets consist of sign/verify, encrypt/decrypt, and Secure Sockets Layer (SSL) authentication certificates. You can use a single set of certificates for all partners, or you can use a unique set of certificates for each sender/receiver pair (or selected pairs). For example, you can use one set of certificates for sending documents from A to B, and a different set of certificates for sending documents from C to A.

When you define your profile and the profiles of your trading partners, you specify the following kinds of certificates in the sender or receiver profiles:

The table lists the certificate action based on the profile and the intended purpose:
Certificate Action Profile Type Purpose
Sign Sender’s profile When you sign a document to send to a partner, Trading Networks looks at your profile to see if it contains the specific private key to use to sign the document.
Verify Sender’s profile When a partner sends a document to you, Trading Networks looks at the sender’s profile to see if it contains the specific public certificate to use to verify the document.
Encrypt Receiver’s profile When you encrypt a document to send to a partner, Trading Networks looks at the receiver's profile to see if it contains the specific public certificate to use to encrypt the document.
Decrypt Receiver’s profile When a partner sends an encrypted document to you, Trading Networks looks at your profile to see if it contains the specific private key to use to decrypt the document.
SSL Sender’s profile This certificate represents the partner’s authentication credentials when making an SSL connection with Integration Server.

Certificates associated with partner profiles are stored in separate files in the Trading Networks database. Certificates associated with Enterprise profiles are stored in keystore files on Integration Server.

Keystores consist of one or more pairs of private keys and signed certificates for their corresponding public keys. Each key pair is identified by a unique key alias. Keystores are identified by a unique keystore alias.

You create and edit keystore aliases for certificates associated with Enterprise profiles from the Security > Keystore panel in Integration Server Administrator. You create key aliases to identify specific keys within a keystore using a third-party certificate management tool.

For more information about keystores and certificates, see webMethods Integration Server Administrator’s Guide.

Overlapping of Certificates

Edit online
You can upload up to two active certificate sets each (referred to as the primary and secondary certificate sets) for sign/verify, encrypt/decrypt, and SSL certificate types, so that when one certificate set expires, Trading Networks can switch to the other one without interrupting the processing of documents. The certificate set that you add first is the primary certificate set. Trading Networks automatically switches from the primary certificate set to the secondary one when any of the following occurs:
  • The primary certificate has expired and the secondary certificate has not expired.
  • The receiver's sign/verify or SSL primary certificate set does not match the sender's sign/verify or SSL certificate set.

    Trading Networks does not switch encryption/decryption certificates at the receiver’s end. The receiver of the document must write a flow service that first obtains the certificate ID of the appropriate decrypt certificate, using the wm.tn.security:getAllCertificateData service, and then set that certificate as the primary one for that partner, using the wm.tn.security:setPrimaryCertificate service. Doing so ensures that the correct decryption certificate is retrieved for future transactions with that partner.

The following diagram illustrates the sign/verify, encryption/decryption, and SSL scenario one:
The table describes the actions illustrated in the diagram for sign/verify, encryption/decryption, and SSL scenario one:
Step Description
1 The trading partner sends a document signed with certificate C1 to the enterprise.
2 Trading Networks on the enterprise side retrieves the certificate C1 for the trading partner from Trading Networks.
3 Trading Networks on the enterprise side verifies the document with C1. Verification is successful.

The following diagram illustrates the sign/verify, encryption/decryption, and SSL scenario two:

The table describes the actions illustrated in the diagram for sign/verify, encryption/decryption, and SSL scenario two:
Step Description
1 The trading partner sends a document signed with C2 certificate to the enterprise.
2 Trading Networks on the enterprise side switches the primary certificate to C2 and retrieves the certificate C2 because certificate C1 has expired.
3 Trading Networkson the enterprise side verifies the document with C2. Verification is successful.

The following diagram illustrates the sign/verify, encryption/decryption, and SSL scenario three:

The table describes the actions illustrated in the diagram for sign/verify, encryption/decryption, and SSL scenario three:
Step Description
1 The trading partner sends a document signed with certificate C2 to the enterprise.
2 Trading Networks on the enterprise side retrieves the certificate C1 for the trading partner from Trading Networks and verifies the document with certificate C1. Verification fails as the document is signed with the certificate C2.
3 Trading Networks on the enterprise side retrieves the certificate C2 and verifies the document with C2. Verification is successful.
4 Trading Networks on the enterprise side sets the certificate C2 as the primary certificate for the trading partner.

The following diagram illustrates the sign/verify, encryption/decryption, and SSL scenario four:

The table describes the actions illustrated in the diagram for sign/verify, encryption/decryption, and SSL scenario four:
Step Description
1 The encryption module on the trading partner requests the encryption certificate and gets the primary certificate C1.
2 The encryption module on the trading partner encrypts the document with the certificate C1 and sends the document to the enterprise.
3 The decryption module on the enterprise side requests Trading Networks for the decryption certificate and gets the certificate C1.
4 The decryption module on the enterprise side decrypts the document using certificate C1. Decryption is successful.

The following diagram illustrates the sign/verify, encryption/decryption, and SSL scenario five:

The table describes the actions illustrated in the diagram for sign/verify, encryption/decryption, and SSL scenario five:
Step Description
1 The encryption module on the trading partner requests the encryption certificate and gets the certificate C2 because C1 has expired.
2 The encryption module on the trading partner encrypts the document with the certificate C2 and sends the document to the enterprise.
3 The decryption module on the enterprise side requests Trading Networks for the decryption certificate.
4 Trading Networks on the enterprise side switches the primary certificate to C2 because certificate C1 has expired, and returns C2.
5 The decryption module on the enterprise decrypts the document using certificate C2. Decryption is successful.

The following diagram illustrates scenario the sign/verify, encryption/decryption, and SSL scenario six:

The table describes the actions illustrated in the diagram for sign/verify, encryption/decryption, and SSL scenario six:
Step Description
1 The encryption module on the trading partner requests the encryption certificate and gets the certificate C2.
2 The encryption module on the trading partner encrypts the document with the certificate C2 and sends the document to the enterprise.
3 The decryption module on the enterprise side requests Trading Networks for the decryption certificate and gets the certificate C1.
4 The decryption module on the enterprise side decrypts the document using certificate C1. Decryption fails.
5 The decryption module requests for the secondary certificate C2 using the wm.tn.security:getAllCertificateData service.
6 The decryption module decrypts the document with certificate C2. Decryption is successful.
7 The decryption module calls the Trading Networks  setPrimaryCertificate service to switch the primary certificate to C2.

The following diagram illustrates the sign/verify, encryption/decryption, and SSL scenario seven:

The table describes the actions illustrated in the diagram for sign/verify, encryption/decryption, and SSL scenario seven:
Step Description
1 The enterprise sends a document to the trading partner over HTTPS using the private key from certificate C1.
2 The trading partner's server authenticates the document using the SSL certificate C1 configured on the server. Authentication is successful and the transaction is complete.

The following diagram illustrates the sign/verify, encryption/decryption, and SSL scenario eight:

The table describes the actions illustrated in the diagram for sign/verify, encryption/decryption, and SSL scenario eight:
Step Description
1 The enterprise sends a secure document to the trading partner over HTTPS using the private key from certificate C1.
2 The trading partner's server authenticates the document using the SSL certificate C2 configured on the server. Authentication fails.
3 The trading partner's server sends an error message to the enterprise.
4 The enterprise switches the SSL certificate to C2 and resends the document to the trading partner over HTTPS.
5 The server on the trading partner authenticates the document using the SSL certificate C2 configured on the server. Authentication is successful. The transaction is complete.

Verifying Digital Signatures

Edit online

Trading Networks supports x.509v3 certificates for verifying the digital signature of documents sent by a partner. Trading Networks verifies the digital signature to make sure the documents have arrived unchanged and the sender is who it claims to be. To verify the digital signature, you do the following:

  • Save the partner’s Verify certificate in the partner’s profile. Trading Networks must have access to the partner’s certificates. When you add a Verify certificate, Trading Networks stores the certificate in its database.
    Note: If you include the private key in the certificate information, Trading Networks can also use this information to digitally sign documents on behalf of the partner. You might have the private key if the profile describes an internal group (for example, a department within your corporation).
  • For XML documents, set up the document type to extract the SignedBody and Signature system attributes. The SignedBody attribute identifies the portion of the document that was digitally signed. The Signature attribute identifies the portion of the document that contains the digital signature. The signature must be a base64 encoded PKCS#7 detached digital signature and can contain information for one or more signers.
  • Specify the Verify Digital Signature pre-processing action in the document type or processing rule.

When a partner sends a document to you, Trading Networks looks at the partner’s profile to see if it contains the specific public certificate to use to verify the document. If Trading Networks finds a set of certificates to use for that specific receiver, it uses the appropriate certificate in that set. If Trading Networks does not find a set of certificates to use for that specific receiver, it uses the default set of certificates specified in the partner’s profile.

To verify that the document arrived unchanged from the partner to you, Trading Networks invokes the Integration Server pub.security.pkcs7:verify built-in service. Trading Networks passes this service the value of the SignedBody and Signature system attributes that it extracted from the document.

Trading Networks can only verify information on itself because it does not have the certification/verification for the partner. Trading Networks makes sure that the CA that signed the certificate is included in the list of trusted CA certificates that the Integration Server maintains.

To ensure that the signed body has not changed, Trading Networks verifies the digital signature, which is the value of the Signature system attribute. To verify that the sender is who it claims to be, Trading Networks matches the certificate from the digital signature to the Verify certificate that Trading Networks has on file for the partner.

Digitally Signing Documents

Edit online

Trading Networks supports x.509v3 certificates for digitally signing documents that you, the owner of the certificates, want to send to trading partners. To digitally sign a document, you invoke the wm.tn.doc:sign built-in service.

When you invoke this service, Trading Networks locates the sender and receiver to retrieve the correct signed certificate from the Trading Networks database. The owner of the certificate is the sender, and the receiver is the trading partner. You can set up Trading Networks to use different certificates for different partners.

You can also specify a default Sign certificate by providing the certificate information in the owner’s profile. If a default Sign certificate is defined, then Trading Networks uses this default Sign certificate when a partner-specific Sign certificate is not available.

When you sign a document to send to a partner, Trading Networks looks at your profile to see if it contains the specific private key to use to sign the document. If Trading Networks finds a set of certificates to use for that specific receiver, it uses the appropriate certificate in that set. If Trading Networks does not find a set of certificates to use for that specific receiver, it uses the default set of certificates specified in your profile.

Encrypting and Decrypting Data

Edit online

Trading Networks does not encrypt or decrypt documents. However, Trading Networks maintains x.509v3 certificates for other webMethods components, such as webMethods RosettaNet Module. These certificates are used for encrypting documents that are sent to partners and decrypting the encrypted documents that are received from partners.

If the other webMethods components, such as webMethods RosettaNet Module requires Encrypt certificates, save a partner’s Encrypt certificate in the partner’s profile. You can also add your own functionality that takes advantage of this certificate information. You can obtain the certification information by using built-in services.

Note: Trading Networks does not check to see if the CA that signed the Encrypt certificate is in the list of trusted CAs that the Integration Server maintains. If you include the private key in this certificate information, this certificate information can also be used to decrypt documents that were encrypted with the partner’s public key. You might have the private key if the profile describes an internal group, for example a department within your corporation.

When you encrypt a document to send to a partner, Trading Networks looks at the partner’s profile to see if it contains the specific public certificate to use to encrypt the document. If Trading Networks finds a set of certificates to use for that specific receiver, it uses the appropriate certificate in that set. If Trading Networks does not find a set of certificates to use for that specific receiver, it uses the default set of certificates specified in the partner’s profile.

If the webMethods components require Decrypt certificates, save your Decrypt certificate in the owner’s profile. Because you can store Decrypt certificates in the owner’s profile, you can set up alternate Decrypt certificates for different partners. You can also specify a default Decrypt certificate by providing the certificate information in the owner’s profile. If a default Decrypt certificate is defined, then Trading Networks will use this default Decrypt certificate when a partner-specific Decrypt certificate is not available.

Note: Trading Networks does not check to see if the CA that signed the Decrypt certificate is in the list of trusted CAs that the Integration Server maintains.

When a partner sends an encrypted document to you, Trading Networks looks at your profile to see if it contains the specific private key to use to decrypt the document. If Trading Networks finds a set of certificates to use for that specific receiver, it uses the appropriate private key in that set. If Trading Networks does not find a set of certificates to use for that specific receiver, it uses the default set of private keys defined in the Default profile for partners.

Communicating Securely Using SSL

Edit online

Because Trading Networks runs in Integration Server, it takes advantage of Integration Server features, such as its support of SSL for secure communications. To enable Trading Networks to act as an SSL client connecting to a remote secure server, you specify an SSL client certificate in your Enterprise profile or your partner’s profile.

When using SSL connections that require client-side authentication, Trading Networks looks at the sender’s profile to see whether it contains the specific private key to use to connect to the receiver (the remote secure server).

The table lists the type of secure communication that Trading Networks uses for the three situations:
Situation Secure Communication that Trading Networks uses
Finds a set of certificates to use for that specific receiver The private key from that certificate set.
Does not find a set of certificates to use for that specific receiver The default private key specified in the sender’s profile.
Does not find a default private key specified in the sender’s profile The default certificates specified in the Integration Server.

Run-Time Event Notifications

Edit online

Run-time events occur on a continuous basis as Trading Networks processes a document or performs a post-processing task. Trading Networks supports run-time event notification using webMethods Event Routing. Event Routing is a framework that Software AG provides for applications to communicate using events. For more information about using Event Routing, see Communicating Between Software AG Products Using Event Routing.

Trading Networks publishes two types of run-time events:
  • Transaction events. Occur when Trading Networks processes a document.
  • Task events. Occur when Trading Networks performs a post-processing task on a document (for example, send document).

To enable Trading Networks to publish run-time events, be sure to enable the event groups by setting the event properties for the corresponding event groups to true. For more information on event groups and event properties, see Event Groups.

Software AG Intelligent Business Operations (IBO) platform-based applications can use these run-time events to generate static or real-time reports.

Caching

Edit online

A cache is a small fast memory holding recently accessed data, designed to speed up subsequent access to the same data.

Terracotta Ehcache is a standards-based caching API that enables applications to fetch frequently used data from an in-memory cache rather than having to retrieve it from a database or other back-end system.

Trading Networks uses the caching capabilities of Terracotta Ehcache to provide:
  • Asset caching. Trading Networks uses Terracotta Ehcache to cache assets. While the assets are in cache, Trading Networks can quickly retrieve them for similar requests, rather than getting the details from Trading Networks database. For more information about asset caching, see Asset Caching.
  • Query results caching. Trading Networks uses Terracotta Ehcache to store the results of a database query. It stores the number of rows you specify in a session object on the host Integration Server and stores the remaining rows in Terracotta Ehcache. For more information about query results caching, see Query Results Caching.

For an introduction to Terracotta Ehcache and information for sizing Trading Networks system caches, see Using BigMemory with webMethods Products.

Dashboards and Charts

Edit online

Trading Networks provides a set of dashboards and charts that give you a graphical view of partners and their transactions on a daily, weekly, and monthly basis. You can view the transaction volume summary, the transaction volume and total value trend for an attribute, successful and failed transactions, late FA count by partners and so on.

For more information on dashboards and charts, see Working with Dashboards and Charts.

Database Partitioning

Edit online

Database partitioning logically separates one set of data from the other, thereby enhancing performance especially while archiving data from Trading Networks production tables to archive tables. For more information on database partitioning, see Database Partitioning.