Copyright © TIBCO Software Inc. All Rights Reserved

Overview

The exchange of business documents is known as the process flow. In any BusinessConnect process flow, two types of messages are exchanged:

•	Public messages or operations

•	Private messages. See Private Messages.

About Services Plug-in Operations

Public messages are exchanged over the Internet between BusinessConnect and another B2B installation. The following message types are supported in the Services Plug-in:

•	Notify Operation

•	Synchronous Request Response Operation

•	Asynchronous Request Response Operation

About Schema Validation in the Services Plug-in

Schema validation in the Services Plug-in is performed based on the following:

•	Schema type: XSD or DTD

•	Direction of messages

•	Whether the validation is done for a request or for a response

Caching of Schemas

The referenced schema is updated in the validator cache during runtime validation, in the same way as if it was saved through the GUI.

When a schema is used by reference, you do not observe any schema changes in the referenced object but you could see the change on the reference instead. This means that the TIBCO BusinessConnect configuration store does not scan the referenced object each time the validation occurs, but it instead indicates if there is a change in the uploaded file object. You need to update the reference in the GUI — re-save the schema reference — and the new referenced object is updated in the cache.

See also Validation Schema Name for more information about how to choose which schema to use: XSD or DTD.

Duplicate Message Detection

The Services Plug-in allows both incoming and outgoing public messages to be verified for duplicates. A message is determined to be a duplicate based on the certain message field values such as transactionID, operationID , and so on.

For each message, a message digest from the predetermined fields is created and stored in a table. If any subsequent message has the same message digest, it is considered to be a duplicate message. If requested by the user, all incoming requests are checked for duplicates.

Both the inbound and outbound requests for a trading partner can be configured for the duplicate detection.

If the duplicate detection for the outbound messages is enabled, all the incoming private process messages are checked for duplicate detection. If a request is found to be a duplicate, the transaction is terminated and an error advisory is sent to the private process.

For the inbound requests, the private process is notified by setting the duplicate field to true, while it is up to the private process to take further action.

Outbound Duplicate Detection Criteria

For asynchronous and synchronous responses, outbound duplicate detection is not supported (only inbound duplicate detection is supported).

The following fields from the private process are used in calculating the message digest for duplicate detection for outbound requests:

•	TransactionID received from the user

When the outbound File poller initiates a transaction, the transactionID element is used for calculating the message digest.

•	Payload: plainRequest, binaryRequest, inputFileName (file content)

•	Trading partner host name

•	Operation ID

•

Host name

Inbound Duplicate Detection Criteria

For asynchronous and synchronous responses, only inbound duplicate detection is supported.

The following values from the incoming request are used in calculating the message digest for duplicate detection for inbound requests.

•

Payload

•	Trading partner name

•	Operation ID

If an error occurs during the transaction processing, the duplicate detection entry from the table BC_DUP is deleted.

Copyright © TIBCO Software Inc. All Rights Reserved