Various Acknowledgement in EDI

I have already talked a little bit about Functional Acknowledgement. Typically it is called 997 in X12 and is defined in each and every version of X12 such as 4010,4020 etc, where as the same is called Control in EDIFACT and is of version D3.

In the EDI world, people often get confused Functional Acnowledgement with Exchange/Transport level acknowledgement and also the Application level confirmation such as Purchase order Acknowledgment such as 855.

Exchange Level Acknowledgement/Trnasport Level :

Acknowledgement such as MDN i.e Message disposition notification in AS2 or Acknowledgement in EBMS specified the aknowledgement of the business message
in the enterprise only w.r.t meeting the security aspects such as verifying the signed message and decrypting the encrypted message and uncompress it if it is a compressed message and it do nothing w.r.t the payload validity or the business level integration.

Functional Acknowledgement :

Functional Acknowledgement as a Best Practices is handled in most of
the cases using B2B Application level and it caters to validation of the business message w.r.t any defined grammer such as schema,DTD or anything specific to EDI and it also specifies the translation status etc.

It is also possible to handle this in the back end application by delegating the Functioanl Acknowledgement generation to the back end application , however the correllation happens in the B2B.

The flag isFunctionalAck required controls whether an ACK) is needed are not. The flag isFunctionalAclHandledbyB2B controls whether FA is required and it is generated in B2B or it comes from Back End application such as BPEL. This option is useful only when isFunctionalAck required is YES. The flag isFunctionalAclHandledbyB2B should be set to 'YES', unless there is special way ACK is generated outside B2B. Functional Ack is generated using the XEngine in B2B and captures all the translation and validation errors.

To enqueue a query response from BPEL to B2B, populate the replyToMsgID field of
IPMessage with the MsgID field of the incoming message.

Application Acknowledgement :

Application Acknowledgement such as Purchase order Acknowledgement is from the ERP application and caters to the process integration status.

Custom Code List - EDI

Use case : using Interchange Receiver ID qualifier or Interchange Sender ID qualifier ZZ which is not there in the standard code list as part of the Document Protocol Parameter configuration.

Follow the below steps.

1. Modify the interchange ecs file to add the "ZZ" in the standard code list_007.
2. This can be done by editing the Interchange ecs file in the spec builder and adding zz in the S003/007/Standard Code List_007
3. Use the updated ecs while configuring the EDIFACT document protocol parameter as interchange ECS.
4. re-deploy the agreement after validation.
5. Make sure your transactionset ecs do not have any envelope information.

How to test:

Exhange an EDI document whose Interchange Receiver ID as ZZ. It should work :)

Latest B2B Patch and Features Incorporated

Latest B2B Patch is Latest patch : 6673231
. Following are the list of features as part of this patch.

1. Identification of Trading partner based on Exchange/Interchange

Trading partner Identification Any (newly Added)

If property is set to ANY, B2B will first try to identify TP using Interchange. If no TP found using Interchange, B2B will next try to find TP based on Group.

2. Performance improvement in EDI Batching.

3. SFTP

4. Large EDI Message Processing. Tested more than 300 MB file.

5. Sending one Ack for all the messages in the Batch.

6. IMMEDIATE HL7 ACK AND ANONYMOUS TP

Already discussed about this in another thread.

7. Self Service API Enhancement to address the same Trading partner being intiator and responsder for a business action corresponding to same Document Type and revision.

Oracle AS B2B - Various Features in FTP Adapter (FTPS, SFTP...)

As part of the Oracle AS B2B 10.1.2.0.2 FTP adapter offering following features are supported. FTP Protocol forms part of the Generic Exchange Plugin.

1. Basic FTP

Identification of Trading Partner Criterion is slightly different for Internal and External Delivery channel, even though identification is based on the "Name" in both of this cases.

a. For External Delivery Channel.

i. Identification of Trading Partner is based on the name of the file and the name shoud follow the patterns as nameOfTP_UniqueID.

ii.Identification of Trading Partneris based on the name of the Directory. To enable this it is required to set

oracle.tip.adapter.b2b.allTPInOneDirectory= True as part of tip.properties setting.

b. For Internal Delivery Channel.

The identification of Trading partner and the Document is based on the name of the file and should follow the pattern as
TradingPartner_DocumentType_Revision_msgType_msgId_replytoMsgID_extension.xml


2. FTPS : FTP OVer SSL

Download any of the FTP server which can be configured to FTPS such as FIlezilla. Configure FTP server for FTPS as per the FTP server documentation. The SSL configuration is driven by the value of parameter "Channel mask" , please use it accordingly.


Oracle AS B2B Configurtion:

1. Depending on the mode of data transfer i.e Active/Passive , specify the data port for Active configuration and no data port for passive mode. Control port is there for both the mode and by default B2B considers this to be 21, there is a need to
mention it for any deviation.

2. Receiver Channel Mask (Host) : Depending on whether No channel encrypted, data channel to be encrypted , Control Channel to be encrypted or Both control and Data channel to be encrypted specity none, Data, Control or Both accordingly.

2. Sender Channel Mask (Trading Partner) : Depending on whether No channel encrypted, data channel to be encrypted , Control Channel to be encrypted or Both control and Data channel to be encrypted specity none, Data, Control or Both accordingly.

Refer to the user guide for FTP Transport configuration.


3. SFTP(New Feature available as part of latest B2B patch # 6353697)

P.S If SFTP protocol is not seeded , please seed it using

%ORACLE_HOME%\jdk\bin\java oracle.tip.seed.SFTPSeedDriver

SFTP implementation has been provided for Oracle B2B 10.1.2.0.2 version. This enables B2B to send and receive payload files over SFTP (SSH FTP) protocol.

SFTP protocol support added for both external trading partners and internal applications communications. The naming conventions of the payload files are in-line with File and FTP adapters.

Proxy support provided (HTTP)

Authentication Support :
Password based authentication – username/password combination authentication

Public key authentication – authenticating the identity based on the public key

create a key pair using OpenSSL keygen tool and the Public key need to be installed in the server. and the private keys fully qualified file location has to be specified in Private Key file and the passphrase has to be provide in Prive Key Pass phrase.

If the passphrase is present in the FTP configuration, B2B engine considers the password based Authentication else key based Authentication otherwise it is key based Authentication.

EDI Van Migration to AS2 Protocol considerations.

Coming Soon. Please check back often.

Creating B2B Metadata Using Self Service API

The Self-service API for Trading Partners and Agreements creation

The primary way to manage trading partners in the Oracle Integration B2B product is through the web-based GUI. This GUI allows authorized users to create, update, delete and validate trading partners and agreements, and to create and deploy configurations. However, there frequently is a need to create trading partners and agreements “on the fly” i.e. programmatically. There also exist situations where a commandline-based way to create trading partners and agreements may be appropriate, such as when needing create trading partners in “bulk”, where it can get really tedious, if not downright impossible to create huge numbers of trading partners using the GUI.

The new Trading Partner self-service API was developed due to these needs, and is driven primarily through XML-based descriptors for Trading Partners and Agreements. This document details the formats of these XML Trading Partner and Agreement descriptors, the usage of the Trading Partner Self-Service API, its capabilities and restrictions, and also includes some samples.

The Trading Partner descriptor XML

A trading partner’s characteristics and capabilities are described through an XML file, whose format is defined by the XSD referenced in the appendix. In this section, we will look at the elements and attributes that make up this XML file.

TradingPartners: The root element that contains 1 or more TradingPartner profiles.
TradingPartnerProfile: This element contains all the information needed to create a Trading Partner and hence is the "root" for a single trading partner. There can be many such elements under the "TradingPartners" element.
Attribute TPName: This specifies the "Name" of the trading partner.
Attribute Description: An optional description for the TradingPartner is specified here.

TradingPartnerID: This element is used to specify zero or more trading partner IDs.
Attribute Type: Specifies the type of the Identification.
Attribute Value: Specifies the value for this type of identification.
Attribute Description: Provides an optional description for the TP ID type.

OperationalCapability: This element contains all the information that describes the operational capability of a trading partner.

SupportedBusinessAction: Describes a SupportedBusinessAction for the trading partner.
Attribute BusinessActionName: Specifies the name of the BusinessAction supported by this trading partner.
Attribute isInitiator: Specifies if the trading partner is the initiator of the business action.
Attribute isFunctionalAckReqd: Specifies if the functional ack is required.

DocumentType: This element is used to specify any DocumentTypeParameters that need to be different from the protocol default, as well as the DocumentDefinition.
Attribute Name: Name of the DocumentType
Attribute Protocol: The name of the document protocol.
Attribute Version: the version of the document protocol.

DocumentTypeParameter: Specifies zero or more DocumentTypeParameters and their values that need to be different from the defaults.
Attribute Name: The name of the Parameter
Attribute Value: The value of the Parameter

DocumentDefinition: Contains information pertaining to the DocumentDefinition.
Attribute Name: The name of the DocumentDefinition
Attribute Description: An optional description for the DocumentDefinition.
Attribute isTranslationEnabled: Indicates if translation should be performed.
Attribute isValidationEnabled: indicates if validation should be performed.
Attribute Definition: Specifies the full path to the file containing the definition (e.g. and XSD file).


CommunicationCapability: This element contains all information pertaining to the communication capbilities of a trading partner.

DeliveryChannel: This element contains information regarding a delivery channel for a trading partner.
Attribute ReceiptNonRepudiation: indicates whether non-repudiation of receipt is required.
Attribute OriginNonRepudiation: indicates whether non-repudiation of origin is required.
Attribute EncryptionEnabled: indicates whether encryption is enabled.
Attribute CompressionEnabled: indicates if compression is enabled.
Attribute TransportSecurityEnabled: indicates whether transport security is enabled. if this is enabled, an HTTP transport would be HTTPS, for example.
Attribute RetryCount: indicates the number of retries.
Attribute TimeToAcknowledge: specified the time window before which an ack is required.
Attribute Name: Specifies the name of the delivery channel; optional. If unspecified, a delivery channel name would be synthesized.

DocumentExchange: Specifies information relating to DocumentExchange for a trading partner.
Attribute Name: Specifies the name of the DocumentExchange; optional. If not specified, and name is synthesized.

ExchangeProtocolRevision: Specifies the ExchangeProtocol.
Attribute Name: Name of the Exchange protocol.
Attribute Version: Specifies the version of the ExchangeProtocol.

ExchangeProtocolParameter: Specifies the ExchangeProtocolParameters that need to be different from the defaults.
Attribute Name: The name of the Parameter
Attribute Value: The value of the Parameter.

Encryption: Contains information relevant to encryption, such as Certificate location.
Certificate: Contains certification information.
Attribute Name: Name of the certificate.
Attribute Location: Specifies the location of the certificate.

Non-Repudiation: Contains information relevant to non-repudiation.

Transport: Specifies the transport information for this Delivery Channel.
Attribute Name: Name of the transport, and is optional. If unspecified, a name will be synthesized.
Attribute URI: The URI/endpoint used by this transport.

TransportServer: Specifies the transport information for this Delivery Channel.
Attribute Name: Name of the transport server, and is optional. If unspecified, one will be synthesized.
Attribute Description: an optional description for the transport server
Attribute HostName: This is required if TransportServer needs to be created
Attribute IPAddress: IPAddress of the host, and is optional.
Attribute UserName: This is required for a new TransportServer. Specifies the username to use (for protocol such as FTP).
Attribute Password: This is required for a new transport server. Specifies the password to use (e.g. FTP).
TransportProtocol: This element identifies the Transport protocol (HTTP etc.)
Attribute Name: The name of the transport protocol.
Attribute Version: The version of the transport protocol.

TransportProtocolParameter: Specifies transport protocol parameters.
Attribute Name: Name of the Parameter.
Attribute Value: Value of the parameter.

The Agreement XML

The Agreement XML contains the following elements:

TPAgreements: Contains descriptions of one or more agreements.

Agreement: This element contains the description for an Agreement.
Attribute Name: The name of the agreement.
Attribute ID: The ID of the agreement.
Attribute Description: description of the agreement.
Attribute EffectiveFromDate: When the agreement is effective from
Attribute EffectiveToDate: Till when the agreement is effective.
Attribute InvocationLimit: Ceiling for the number of invocations.
Attribute ConcurrentConversations: The max number of concurrent instances of this Agreement.

BusinessActionParticipant: This element describes the participants in this business action.
InitiatingTP: Describes the TP initiating the business action.
Attribute TPIDType: The type of the TP ID used in the agreement.
Attribute TPIDValue: The value of the TP ID used in the agreement.

DeliveryChannel: Describes the delivery channel used in the agreement.
Attribute Name: Name of the delivery channel.

RespondingTP: Describes the responding TP in the business action.
Attribute TPIDType: The type of the TP ID used in the agreement.
Attribute TPIDValue: The value of the TP ID used in the agreement.

InternalDeliveryChannel: Describes the Delivery Channel used in the agreement.
Attribute Name: the name of the internal delivery channel used in the agreement.

CalloutUsage: Describes the call out usage in the agreement.
Attribute Name: Name of the callout usage.

Using the SelfService API

The self-service API can be used by clients programmatically to create Trading Partners and Agreements, or can be used in the command-line mode. To use it in the command line:

· java oracle.tip.adapter.b2b.selfservice.TradingPartnerManager
creates the Trading Partner profiles from the specified XML file.
· java oracle.tip.adapter.b2b.selfservice.AgreementManager creates agreements from the specified XML file.

The following code snippet shows how to use the SelfService API programmatically:
FileInputStream fis = new FileInputStream(tpFile);
InputSource is = new InputSource(fis);
TradingPartnerManager tpMgr = TradingPartnerManager.newInstance();
tpMgr.init();
if (args.length == 2) {
tpMgr.processTPProfiles(is, true);
} else {
tpMgr.processTPProfiles(is, false);
}
tpMgr.shutdown();
FileInputStream fis = new FileInputStream(tpFile);
InputSource is = new InputSource(fis);
AgreementManager agreementMgr = AgreementManager.newInstance();
agreementMgr.init();
agreementMgr.processAgreements(is);
agreementMgr.shutdown();

References

1. TPProfile.xsd
2. Agreements.xsd
3. TPProfile samples
4. Agreements samples.

and can be furnished upon request.