tib bc ezcomm users guide

TIBCO BusinessConnect™

EZComm Protocol User’s GuideSoftware Release 5.3May 2009

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO Software Inc.

TIB, TIBCO, TIBCO Software, TIBCO Adapter, Predictive Business, Information Bus, The Power of Now, TIBCO BusinessConnect, TIBCO Runtime Agent, TIBCO ActiveMatrix BusinessWorks, TIBCO Administrator, TIBCO Designer, TIBCO Rendezvous, and TIBCO Enterprise Message Service are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries.

EJB, J2EE, JMS and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME TIME. SEE THE README.TXT FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.

Copyright © 1999-2009 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information

TIBCO BusinessConnect EZComm Protocol User’s Guide

Contents | iii

Contents

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiTIBCO BusinessConnect Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiOther TIBCO Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

How to Contact TIBCO Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Chapter 1 Introduction to EZComm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

TIBCO BusinessConnect EZComm Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

TIBCO BusinessConnect EZComm Protocol Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 EZComm Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Tutorial Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Create a Deployment Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Edit Application Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Assign Components to Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Deploy and Start the TIBCO BusinessConnect Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Import the Tutorial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Configuring the Initiator TIBCO BusinessConnect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Configure the Initiator Default Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Configure the Initiator Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Configure the Initiator Business Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Configuring the Responder TIBCO BusinessConnect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Configure the Responder Default Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Configure the Responder Partner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Configure the Responder Business Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Configuring the Private Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Open the BusinessWorks Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Configure Connections to Initiator TIBCO BusinessConnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23


iv | Contents

Configure Connections to Responder TIBCO BusinessConnect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Running the Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Run the Tutorial on the Seller Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Run the Tutorial on the Buyer Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27View the Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapter 3 EZComm URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Exchanging URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Email Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34File Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34FTP Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35HTTP/S Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Populating URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 4 Managing EZComm Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40About EZComm Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40About Schema Validation in EZComm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Duplicate Message Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Notify Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Synchronous Request Response Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Asynchronous Request Response Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Configuring EZComm Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Add New Category. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Add New Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Add New Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 5 Managing Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Managing EZComm Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Add a Property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Delete a Property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Set Up the Property ezcomm.notify.email.preserveSubject. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 6 Setting Up Trading Hosts and Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Configuring EZComm for a Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Configure the Initiator Default Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Assign Default Host for Initiator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Configuring EZComm for a Partner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Enable Protocol for Initiator Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60


Contents | v

Chapter 7 Configuring Business Agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Adding a New Business Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Configuring Agreement Protocol Binding for EZComm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Operation Bindings Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Edit Operation Bindings for the Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Edit Operation Bindings for a Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Document Security Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Shadow Credential Usage for EZComm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Transports Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Show Advanced Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Override Settings for the Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Override Settings for the Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapter 8 EZComm Private Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76About EZComm Private Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Initiator Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Responder Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

General Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Multiple Attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Resending EZComm Private Process Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Chapter 9 Viewing Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Configure an Audit Log for EZComm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Non-Repudiation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Configure a Non-Repudiation Log for EZComm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Resend Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Configure a Resend Log for EZComm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Chapter 10 File Pollers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Outbound File Pollers for EZComm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Inbound File Pollers for EZComm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Chapter 11 tibXML Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Example Usage Scenarios for EZComm-to-tibXML Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

New GUI Options for tibXML-to-EZComm Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108


vi | Contents

tibXML Private Process Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Rules for Handling tibXML Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Connection Between tibXML Public and Private Process Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Transports for tibXML Private Process Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Comparing Private Processes Messages Between tibXML and EZComm . . . . . . . . . . . . . . . . . . . . . . . . . 111

tibXML Public Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Inbound Processing Error in tibXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Outbound Public Messages in tibXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Inbound Public Messages in tibXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117tibXML Message Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117tibXML Message Packaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

MIME Message Packaging Options in tibXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Passthrough Mode in tibXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Setting Timing Restrictions in tibXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

tibXML Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Chapter 12 EZComm 5.1 to 5.3 Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Public Messages Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Private Process Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Outbound File Poller Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Chapter 13 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Troubleshooting EZComm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Appendix A FTP Script Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

First Tutorial Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Set Up the First Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Run the First Tutorial Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Expected Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Second Tutorial Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Set Up the Second Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Run the Second Tutorial Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Expected Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Third Tutorial Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Set Up the Third Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Run the Third Tutorial Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Expected Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147


Tables | vii

Tables

Table 1 General Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Table 2 Syntax Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Table 1 New Transport for the Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Table 2 New HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Table 3 Edit Protocol Binding: Operation Binding Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Table 4 Override Outbound Settings: Transports Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17


Table 6 Override Inbound Settings: Transports Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Table 7 Operation Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Table 8 Request Action Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Table 9 Response Action Tab: Synchronous and Asynchronous Request-Response Only . . . . . . . . . . . . 51

Table 10 Host Settings: General Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Table 11 Partner Settings: General Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Table 12 New Transport for the Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62


Table 14 Override Outbound Settings: Operation Settings Tab (All Operations) . . . . . . . . . . . . . . . . . . . . . 67

Table 15 Override Outbound Settings: Actions Tab (Notify and Asynchronous Request-Response Operations) 68

Table 16 Override Outbound Settings: Transports Tab (All Operations) . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Table 17 Override Inbound Settings: Operation Settings Tab (All Operations). . . . . . . . . . . . . . . . . . . . . . . 69

Table 18 Override Inbound Settings: Actions Tab (Synchronous and Asynchronous Request Response) . 70

Table 19 Override Inbound Settings: Transports Tab (All Operations) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Table 20 Configure Transports for the Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Table 21 Edit Protocol Bindings: Advanced Settings for Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Table 22 Edit Protocol Binding: Advanced Settings for Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Table 23 Private Message: InitiatorRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Table 24 Private Message: InitiatorResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Table 25 Private Message: ResponderRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81


viii | Tables

Table 26 Private Message: Responder.Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Table 27 Private Message: Responder.Ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Table 28 Private Message: Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Table 29 Audit Log: Search Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table 30 Audit Log: Advanced Search Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Table 31 Non-Repudiation Log: Search Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Table 32 Non-Repudiation Log: Advanced Search Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Table 33 Resend Log: Resendable Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Table 34 Resend Log: Advanced Search Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Table 35 Resend Log: Resend History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Table 36 Resend Log: Advanced Search Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Table 37 INITIATOR.REQUEST Fields in tibXML 3.6 and EZComm 5.3. . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Table 38 INITIATOR.RESPONSE Fields in tibXML 3.6 and EZComm 5.3 . . . . . . . . . . . . . . . . . . . . . . . . . 113

Table 39 RESPONDER.REQUEST Fields in tibXML 3.6 and EZComm 5.3 . . . . . . . . . . . . . . . . . . . . . . . . 114

Table 40 RESPONDER.RESPONSE Fields in tibXML 3.6 and EZComm 5.3 . . . . . . . . . . . . . . . . . . . . . . . 115


Figures | ix

Figures

Figure 1 Imported Operations Manage Widgets and Widget Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 2 TIBCO Designer: BusinessWorks Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 3 BusinessConnect Server Access Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figure 4 INITIATOR (BusinessConnect Connection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 5 Select Process to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 6 SendRequest (Input) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 7 Create Job for the Send ASyncRequest operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 8 Send INITIATOR.REQUEST and Receive INITIATOR.RESPONSE. . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 9 Send Async Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figure 10 RESPONDER AsynchronousRequestResoponse Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figure 11 Audit Log for the Buyer Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 12 Audit Log for the Seller Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 13 Notify Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Figure 14 Synchronous Request-Response Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figure 15 Tutorial: Asynchronous Request Response Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Figure 16 Configure New Operation for EZComm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figure 17 New Operation Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Figure 18 Initiator Request: Initiator Using tibXML 3.x, Responder Using EZComm 5.3 . . . . . . . . . . . . . . . . 107

Figure 19 Initiator Request: Initiator Using EZComm 5.3, Responder Using tibXML 3.6 . . . . . . . . . . . . . . . . 107

Figure 20 tibXML to EZComm Private Process Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Figure 21 EZComm 5.1 to EZComm 5.3 Private Process Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128


x | Figures


| xi

Preface

TIBCO BusinessConnect™ software is a B2B (business-to-business) gateway that allows your company to engage in electronic commerce with your business partners.

Topics

• Related Documentation, page xii

• Typographical Conventions, page xiv

• How to Contact TIBCO Customer Support, page xvii

This software may be available on multiple operating systems. However, not all operating system platforms for a specific software version are released at the same time. Please see the readme.txt file for the availability of this software version on a specific operating system platform.


xii | Related Documentation

Related Documentation

This section lists documentation resources you may find useful.

TIBCO BusinessConnect DocumentationThe following documents form the BusinessConnect documentation set:

• TIBCO BusinessConnect Concepts: Read this guide to learn about TIBCO BusinessConnect architecture, deployment modes, protocols, and security.

• TIBCO BusinessConnect Server Administration: Read this guide in order to administer (install, operate, and manage) the BusinessConnect server.

• TIBCO BusinessConnect Trading Partner Administration: Read this guide to configure and manage trading partners.

• TIBCO BusinessConnect Palette Reference: Read this guide to learn about the resources available in the TIBCO BusinessConnect Palette for TIBCO BusinessWorks.

• TIBCO BusinessConnect EZComm Protocol User’s Guide: Read this guide to learn about using TIBCO BusinessConnect EZComm Protocol. This guide contains a detailed tutorial, which is a recommended reading for new TIBCO BusinessConnect users.

EZComm is installed with TIBCO BusinessConnect, therefore no separate installation guide for this protocol is provided.

• TIBCO BusinessConnect Scripting Deployment User’s Guide: Read this guide to configure and manage TIBCO BusinessConnect using the command line interface.

• TIBCO BusinessConnect Release Notes: Read this document to learn about new features, changes in functionality, deprecated features, known issues, and closed issues for each release.

This document is supplied for each release and is available only in PDF format.

Other TIBCO Product DocumentationYou may find it useful to read the documentation for the following TIBCO products, which may be used or integrated with BusinessConnect:

• TIBCO Administrator™ software: The software allows you to manage users, machines and applications defined in a TIBCO Administration Domain. The


Preface | xiii

TIBCO Administrator graphical user interface enables users to deploy, monitor, and start and stop TIBCO applications.

• TIBCO ActiveMatrix BusinessWorks™ software: This software is a scalable, extensible, and easy to use integration platform that allows you to develop integration projects. TIBCO BusinessWorks includes a graphical user interface (GUI) for defining business processes and an engine that executes the process.

• TIBCO Designer™ software: This graphical user interface is used for designing and creating integration project configurations and building an Enterprise Archive (EAR) for the project. The EAR can then be used by TIBCO Administrator for deploying and running the application.

• TIBCO Runtime Agent™ software: This software suite is a prerequisite for other TIBCO software products. In addition to TIBCO Runtime Agent components, the software suite includes the third-party libraries used by other TIBCO products such as TIBCO Designer, Java Runtime Environment (JRE), TIBCO Hawk®, and TIBCO Rendezvous®.

• TIBCO Rendezvous®: This software enables programs running on many different kinds of computers on a network to communicate seamlessly. It includes two main components: the Rendezvous programming language interface (API) in several languages, and the Rendezvous daemon.

• TIBCO Enterprise Message Service ™ software: This software provides a message service that enables integration of applications within an enterprise based on the Java Message Service (JMS) specifications.


xiv | Typographical Conventions

Typographical Conventions

The following typographical conventions are used in this manual.

Table 1 General Typographical Conventions

Convention Use

TIBCO_HOME

ENV_HOME

Many TIBCO products must be installed within the same home directory. This directory is referenced in documentation as TIBCO_HOME. The value of TIBCO_HOME depends on the operating system. For example, on Windows systems, the default value is C:\tibco.

Other TIBCO products are installed into an installation environment. Incompatible products and multiple instances of the same product are installed into different installation environments. The directory into which such products are installed is referenced in documentation as ENV_HOME. The value of ENV_HOME depends on the operating system. For example, on Windows systems the default value is C:\tibco.

code font Code font identifies commands, code examples, filenames, pathnames, and output displayed in a command window. For example:

Use MyCommand to start the foo process.

bold code

font Bold code font is used in the following ways:

• In procedures, to indicate what a user types. For example: Type admin.

• In large code samples, to indicate the parts of the sample that are of particular interest.

• In command syntax, to indicate the default parameter for a command. For example, if no parameter is specified, MyCommand is enabled: MyCommand [enable | disable]

italic font Italic font is used in the following ways:

• To indicate a document title. For example: See TIBCO ActiveMatrix BusinessWorks Concepts.

• To introduce new terms For example: A portal page may contain several portlets. Portlets are mini-applications that run in a portal.

• To indicate a variable in a command or code syntax that you must replace. For example: MyCommand PathName


Preface | xv

Key combinations

Key name separated by a plus sign indicate keys pressed simultaneously. For example: Ctrl+C.

Key names separated by a comma and space indicate keys pressed one after the other. For example: Esc, Ctrl+Q.

The note icon indicates information that is of special interest or importance, for example, an additional action required only in certain circumstances.

The tip icon indicates an idea that could be useful, for example, a way to apply the information provided in the current section to achieve a specific result.

The warning icon indicates the potential for a damaging situation, for example, data loss or corruption if certain steps are taken or not taken.

Table 1 General Typographical Conventions (Cont’d)

Convention Use

Table 2 Syntax Typographical Conventions

Convention Use

[ ] An optional item in a command or code syntax.

For example:

MyCommand [optional_parameter] required_parameter

| A logical OR that separates multiple items of which only one may be chosen.

For example, you can select only one of the following parameters:

MyCommand para1 | param2 | param3


xvi | Typographical Conventions

{ } A logical group of items in a command. Other syntax notations may appear within each logical group.

For example, the following command requires two parameters, which can be either the pair param1 and param2, or the pair param3 and param4.

MyCommand {param1 param2} | {param3 param4}

In the next example, the command requires two parameters. The first parameter can be either param1 or param2 and the second can be either param3 or param4:

MyCommand {param1 | param2} {param3 | param4}

In the next example, the command can accept either two or three parameters. The first parameter must be param1. You can optionally include param2 as the second parameter. And the last parameter is either param3 or param4.

MyCommand param1 [param2] {param3 | param4}

Table 2 Syntax Typographical Conventions

Convention Use


Preface | xvii

How to Contact TIBCO Customer Support

For comments or problems with this manual or the software it addresses, please contact TIBCO Support Services as follows.

• For an overview of TIBCO Support Services, and information about getting started with TIBCO Product Support, visit this site:

http://www.tibco.com/services/support

• If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a user name and password. If you do not have a user name, you can request one.


xviii | How to Contact TIBCO Customer Support


| 1

Chapter 1 Introduction to EZComm

It is recommended that all users familiarize themselves with EZComm using this tutorial, which provides valuable insight for using other, more complex protocols.

Topics

• TIBCO BusinessConnect EZComm Protocol Overview, page 2

• TIBCO BusinessConnect EZComm Protocol Features, page 3


2 | Chapter 1 Introduction to EZComm

TIBCO BusinessConnect EZComm Protocol Overview

TIBCO BusinessConnect includes EZComm, an easy-to-use data transfer protocol, which allows you to securely exchange data over the Internet. It provides the basic transport connectivity for trading partners to exchange documents with the BusinessConnect host without conforming to a particular business protocol standard such as EDI, RosettaNet, or SOAP.

Trading partners managed by BusinessConnect can quickly and efficiently be configured to exchange document securely with the BusinessConnect host over the Internet using EZComm without understanding or interpreting the document contents.

With the introduction of the Request/Response operation type, TIBCO BusinessConnect EZComm Protocol allows tracking of each document sent to or received from a trading partner, independent of the transport mechanism, and correlates the corresponding response document with the trading partner. The back office applications can focus on the processing of the document contents sent to or received from BusinessConnect, which ensures that the response document is properly logged with the corresponding request document and delivered or received on time to or from the trading partner.


TIBCO BusinessConnect EZComm Protocol Features | 3

TIBCO BusinessConnect EZComm Protocol Features

TIBCO BusinessConnect EZComm Protocol has the following features:

Automatic Installation

TIBCO BusinessConnect EZComm Protocol installs automatically with TIBCO BusinessConnect.

The complete installation for TIBCO BusinessConnect and EZComm is explained in the TIBCO BusinessConnect Server Administration Guide.

Support for Public Transports

The basic transport connectivity includes the File, Email, HTTP/S, FTP/S, and SSHFTP transports. These transports follow industry transport protocol standards such as AS1, AS2, SMTP, POP, S/MIME, SSH, SSL to provide document security by encryption and document authenticity by digital signature.

To learn more about public transports and their configuration, see TIBCO BusinessConnect Trading Partner Administration Guide and the following chapters:

• Chapter 10, HTTP, HTTPS, and HTTPSCA Transports

• Chapter 12, AS1 Transport

• Chapter 13, Email Transport. See also Content Disposition Filename.

• Chapter 14, FTP and FTPS Transports

• Chapter 15, SSHFTP Transport

• Chapter 16, File Transport

Support for Private Transports

TIBCO BusinessConnect EZComm Protocol supported the following private transports:

• TIBCO Rendezvous

• JMS

These private transports are explained in TIBCO BusinessConnect Concepts, TIBCO Rendezvous and JMS Transport.



Support for Operations

The following operations are supported in TIBCO BusinessConnect EZComm Protocol:

• Notify Operation

Notify operation is a one way operation. It can simply send a document to the trading partner and receive the acknowledgement. Its not capable of receiving the response from the trading partner.

• Synchronous Request Response Operation

Synchronous Request Response operation sends the document to trading partner and waits for the response until the response is received; it suspends any further processing for that request.

• Asynchronous Request Response Operation

Asynchronous Request Response operation sends the document to trading partner and waits for the response, but it allows further processing irrespective of the response arrival from the partner.

XML Validation

EZComm supports XSD and DTD schema validation. To learn more about validating schemas for EZComm, see Configuring EZComm Operations.

tibXML Protocol Integration

EZComm enables interoperability with the legacy protocol tibXML: users of tibXML can communicate with TIBCO BusinessConnect using the EZComm protocol.

See Chapter 11, tibXML Integration for more information.

Support for Multiple Attachments

TIBCO BusinessConnect EZComm Protocol allows multiple attachments. Private process can send these attachments in a sequence and each Attachment has the following structure.

For more information, see Multiple Attachments.

Duplicate Message Detection

EZComm allows both incoming and outgoing public messages to be verified for duplicates.

For more details, see Duplicate Message Detection.


TIBCO BusinessConnect EZComm Protocol Features | 5

Other Supported Features

• Electronic signing and message encryption or decryption

To learn more about security in BusinessConnect, see TIBCO BusinessConnect Concepts, Chapter 8, Security.

• Audit logging, including the user transactionID in the audit log

To learn more about audit logging in EZComm, see Audit Logs.

• Exchange of notices with trading partners

• XML, plain text, and binary data blobs


| 7

Chapter 2 EZComm Tutorial

This chapter presents a complete tutorial on installing and configuring the TIBCO BusinessConnect EZComm Protocol for the Asynchronous Request Response operation.

Topics

• Overview, page 8

• Prerequisites, page 9

• Configuring the Initiator TIBCO BusinessConnect, page 13

• Configuring the Responder TIBCO BusinessConnect, page 18

• Configuring the Private Processes, page 22

• Running the Tutorial, page 26


8 | Chapter 2 EZComm Tutorial

Overview

This tutorial gives an example of an asynchronous Request Response operation in EZComm and shows the following:

• How to create private processes on the Initiator and the Responder side

• How to create and process an asynchronous Request Response operation

Two machines are needed to run the tutorial: Buyer and Seller.

In this tutorial, the Initiator machine is called Buyer and the Responder machine is called Seller.

For an overview of the operation, see Asynchronous Request Response Operation.

Tutorial StepsThis tutorial requires that you follow through the following steps:

1. Prerequisites.

This step is performed both on the Initiator and on the Responder machine.

2. Import the Tutorial


3. Configuring the Initiator TIBCO BusinessConnect

This step is performed only on the Initiator machine.

4. Configuring the Responder TIBCO BusinessConnect

This step is performed only on the Responder machine.

5. Configuring the Private Processes


6. Running the Tutorial



Prerequisites | 9

Prerequisites

Before starting this tutorial, provide the following prerequisites:

1. Install the following software packages:

a. TIBCO BusinessConnect 5.3.0

b. TIBCO BusinessConnect EZComm Protocol

2. Perform all pre-deployment configuration procedures described in TIBCO BusinessConnect Server Administration Guide, Chapter 2, Pre-Deployment Configuration.

3. Deploy and start TIBCO BusinessConnect by performing the steps described in TIBCO BusinessConnect Server Administration Guide, Chapter 3, Deployment.

These steps are also explained in the following sections, using the single server deployment mode:

a. Create a Deployment Configuration

b. Edit Application Configuration

c. Assign Components to Machines

d. Deploy and Start the TIBCO BusinessConnect Instance

4. Import the pre-configured operations to use in the tutorial, as explained in the section Import the Tutorial.

Create a Deployment Configuration1. Start TIBCO Administrator, log in, and in the left panel expand

BusinessConnect by clicking on the plus sign (+).

2. Click on System Settings.

3. Click on Deployment Configuration.

4. Select the Single Server Mode radio button. This will locate all TIBCO BusinessConnect components on one machine.

5. Click Create Deployment Configuration.

When complete, the following message will be displayed: “Deployment Configuration Successfully Created”.

6. Click Done.



Edit Application Configuration1. In the left panel of TIBCO Administrator, expand Application Management.

2. Expand BusinessConnect.

3. Click the Configuration link. The Configuration dialog appears in the right panel. In the Deployability column, there is a message Needs configuration next to the BusinessConnect and Single Server.par links.

4. Click the BusinessConnect link.

The Edit Application Configuration dialog appears. You can configure large and shared file location (optional), as well as the server transport, as explained in the following sections:

— Configure Advanced Settings

— Set Up Server Transport

Configure Advanced Settings

If you need to configure specific directories, see TIBCO BusinessConnect Server Administration Guide, Configure Large, Shared, and Temp File Locations.

• Click Save twice.

The configuration dialog appears indicating the following:

TIBCO BusinessConnect: Services require configuration

Single Server.par: Need to deploy in a Service Container

Set Up Server Transport

1. Click on the TIBCO BusinessConnect link.

The Edit Application Configuration dialog shows up with the Public Process Configuration tab already selected.

2. Click the HTTP link.

3. Select the Enable HTTP Transport checkbox.

4. For the HTTP Port, keep the default value of 6700.

5. Click Save twice.

Large, shared, and temp files will be posted by default to the location “./”, which uses the engine’s running directory as the root folder for all temporary files. If you don’t have any specific requirements, you can leave this directory as is.


Prerequisites | 11

Assign Components to Machines1. Click the Single_Server.par link in the Configuration Builder panel.

The Edit Service Configuration dialog appears with the General tab already selected.

2. Keep the Enable Service checkbox selected.

3. Click Add to Additional Machines.

4. In the Bind to Containers dialog, select the checkbox next to the machine on which you want to deploy this component, searching for it if necessary.

5. Click OK.

In the Edit Service Configuration dialog, the machine you added is now displayed in the Service Instance column.

6. Click Save.


TIBCO BusinessConnect: Deployable, services require deployment

Single Server.par: Deployable, (New)

Deploy and Start the TIBCO BusinessConnect Instance1. Click Deploy.

In the Deploy Configuration dialog, keep the following defaults:

— Stop running services before deployment: keep selected

— Kill services that haven’t stopped after (seconds) : keep 5

— Start successfully deployed services: keep selected

— Force redeployment of all services: default is to keep cleared

2. Click OK.

If you have left the checkbox Start successfully deployed services selected, the TIBCO BusinessConnect engine will be deployed and then started.


Configuration Builder, TIBCO BusinessConnect: Synchronized

Deployed Configuration, TIBCO BusinessConnect: Success



Import the TutorialBefore you can configure partners for an EZComm transactions, you must first configure an operation for EZComm as explained in Configuring EZComm Operations.

This tutorial will use pre-configured operations, which will be imported together with the tutorial.

To import the tutorial on both machines (Initiator and Responder), do the following:

1. Using TIBCO Administrator, select BusinessConnect>Operations Editor.

In the Operations Editor dialog, select EZComm in the dropdown list

2. Click Edit.

3. In the Edit Operations dialog, click Import.

4. Click the link change and upload the following file:

BC_home/samples/EZComm/interfaces/ezcommtutorial-operations.csx

5. Enter the password if desired.

6. Click Import.

This will import two operations named Manage Widgets and Widget Inventory. The default Notify operation and the two imported operations will appear in the Edit Operations dialog:

Figure 1 Imported Operations Manage Widgets and Widget Inventory

Once the operations are imported, continue with configuring the machines.


Configuring the Initiator TIBCO BusinessConnect | 13

Configuring the Initiator TIBCO BusinessConnect

In this tutorial, the hosts machine’s name is Buyer, and the partner’s machine name is Seller.

Follow the steps as described in these sections:

• Configure the Initiator Default Host

• Configure the Initiator Partner

• Configure the Initiator Business Agreement

Configure the Initiator Default Host

1. Select BusinessConnect>Participants.

2. Click the Participant Wizard button.

3. Type Buyer in the Participant Name field.

4. Select Host in the Participant Type dropdown list.

5. Click Finish.

6. Click the Buyer link.

7. In the Edit Host Participant dialog, select the Active checkbox.

8. Click Apply.

9. Select BusinessConnect>System Settings in the left panel.

10. Click the General Settings link.

The Edit System Settings: General Settings dialog appears.

11. Select Buyer in the Default Host dropdown list.

12. Click Save.

For more information about setting up a host in a business agreement, see Configuring EZComm for a Host.

For this tutorial, there is no need to further edit protocol configuration.



Configure the Initiator Partner



3. Type Seller in the Participant Name field.

4. Select Partner in the Participant Type dropdown list.

5. Click Finish.

Both participants (Buyer and Seller) now appear in the panel.

6. Click the Seller link.


8. Click Apply.

Enable Protocolfor Initiator

Partner

9. In the Edit Partner Participant dialog, select the Protocols tab.

10. Click Enable.

The dialog with installed protocols appears.

11. Select the checkbox next to EZComm.

12. Click OK.

The EZComm protocol is now in the Protocol Name list.

Add Transport forInitiator Partner 1. Click on EZComm link.

2. Select the Transports tab.

3. Click Add.

4. In the New Transport dialog, enter the transport name.

For more information about setting up a partner in a business agreement, see Configuring EZComm for a Partner.




5. Enter data for the new transport as explained in Table 1.

6. Click OK.

The New HTTP Transport dialog appears.

Define URL 7. Enter information according to Table 2.

8. Click Save three times.

Table 1 New Transport for the Partner

Field Description

Transport Name Enter the name for the transport (required)

Transport Type Select the transport type from the dropdown list. For this tutorial, select HTTP.

Table 2 New HTTP Transport

Field Description

Transport Name Enter a name for this transport (required)

URL URL of the company (required): www.hostname:6700/EZComm.

Use HTTP Basic Authentication

Clear the checkbox Use HTTP Basic Authentication for this tutorial.

Username No entry required for this tutorial

Password No entry required for this tutorial

Retry Count Leave the default (3).

Retry Interval Leave the default (60).

Socket Timeout (seconds)

Leave the default (300).



Configure the Initiator Business Agreement

After both trading partners are configured, you will now configure their business agreement.

1. Select BusinessConnect>Business Agreements.

2. Click the New button.

The New Agreement dialog appears.

Verify that EZComm appears in the Protocols column for both trading partners. If it is missing, return to Enable Protocol for Initiator Partner and enable the EZComm protocol.

3. Select the host Buyer from the Host Party list.

4. Select the partner Seller from the Partner Party list

5. Click OK.

The New Agreement, general dialog appears.

6. Confirm that the Valid checkbox is selected. This will make the agreement valid immediately.

Add Operation Bindings for the Initiator Business A greement

To add a protocol binding for this business agreement, do the following:

1. Click the Add Protocol Bindings button.

2. Select the EZComm checkbox.

3. Click OK.

EZComm now appears on the Agreement Protocol Binding list.

4. Click Save.

5. Select the business agreement link and then click on the EZComm link.

The Edit Protocol Binding dialog appears with the Operation Bindings tab selected by default.

This section contains only the steps that are necessary for this tutorial. For a complete explanation on this topic, see Adding a New Business Agreement.

This section contains only the steps that are necessary for this tutorial. For a complete explanation on this topic, see Configuring Agreement Protocol Binding for EZComm.



OperationBindings Tab

6. Enter information according to Table 3.

Add Binding forthe Host

7. In the Host can initiate section, click Add Operation Binding.

For this tutorial, select the Manage Widgets/1.0/buyWidgets operation.

8. Click OK.

The selected operation appears in the Operation Name list.

Host can Initiate: Override Outbound Settings

1. Click the operation Manage Widgets/1.0/buyWidgets in the section Host can initiate.

2. Click the Transports tab.

Transports Tab 3. Configure transport settings using Table 4.

4. Click Save.

This creates an operation binding for the operation buyWidget that will override any outgoing request for this operation.

The same binding is used for the incoming response for this request; for example, if you want to override the schema validation for an incoming response, you can select the desired value in the Operation Settings tab for this binding.

Table 3 Edit Protocol Binding: Operation Binding Tab

Field Description

Allow All Operations For this tutorial, clear the Allow All Operations checkbox.

Non-Repudiation Logging

For this tutorial, leave the Non-Repudiation Logging checkbox selected.

Table 4 Override Outbound Settings: Transports Tab

Field Description

Override Transports For this tutorial, select the Override Transports checkbox.

Override Outbound Transports

Primary Transport For this tutorial, select HTTP.



Configuring the Responder TIBCO BusinessConnect

This section describes how to configure the Responder TIBCO BusinessConnect. Configure the Responder on another machine, where your previous host becomes a partner, and the previous partner is now the host. If the second machine doesn’t contain a deployed version of TIBCO BusinessConnect, proceed as follows:

1. Repeat all pre-deployment and deployment steps for the second machine, as described in Prerequisites and Import the Tutorial.

2. Start TIBCO Administrator and click the TIBCO BusinessConnect link.

3. Follow the steps as described in these sections:

— Configure the Responder Default Host

— Configure the Responder Partner

— Configure the Responder Business Agreement

Configure the Responder Default Host



3. Type Seller in the Participant Name field.

4. Select Host in the Participant Type dropdown list and click Finish.

5. Click the Seller link.


7. Click Apply.

8. Select BusinessConnect>System Settings in the left panel.

9. Click the General Settings link. The Edit System Settings: General Settings dialog appears.

10. Select Seller in the Default Host dropdown list and click Save.

For more information about setting up a host in a business agreement, see Configuring EZComm for a Host.



Configuring the Responder TIBCO BusinessConnect | 19

Configure the Responder Partner



3. Type Buyer in the Participant Name field.


5. Click Finish.

6. Click the Buyer link.


8. Click Apply.

Enable Protocolfor Responder

Partner

9. In the Edit Partner Participant dialog, select the Protocols tab.

10. Click Enable.



12. Click OK.


Add Transport forthe Responder

Partner1. Click on EZComm link.

2. Select the Transports tab.

3. Click Add.

4. In the New Transport dialog, enter the transport name.

For more details, see Add Transport for Initiator Partner.

5. Select HTTP from the dropdown list.

6. Click OK.

Define URL 7. The New HTTP Transport dialog appears.

For more information about setting up a partner in a business agreement, see Configuring EZComm for a Partner.




8. Enter the data about this new transport, as explained in Table 2:

www.hostname.com:6700/EZComm.

9. Click Save three times.

Configure the Responder Business Agreement



3. Select the host Seller from the Host Party list.

4. Select the partner Buyer from the Partner Party.

5. Click OK.


7. Click the Add Protocol Bindings button.

8. Select the EZComm checkbox.

9. Click OK.

EZComm now appears on the Agreement Protocol Binding list.

10. Click Save.

Add Operation Bindings for the Responder Business A greement

1. Select the Business Agreement link.

2. In the Edit Agreement dialog, click on the EZComm link.

The Edit Protocol Binding dialog appears with the Operation Bindings tab selected by default.

This section contains only the steps that are necessary for this tutorial. For a complete explanation on this topic, see Adding a New Business Agreement.

This section contains only the steps that are necessary for this tutorial. For a complete explanation on this topic, see Configuring Agreement Protocol Binding for EZComm.


Configuring the Responder TIBCO BusinessConnect | 21

OperationBindings Tab


Add Binding forthe Partner

4. In the Partner can initiate section, click Add Operation Binding.

For this tutorial, select the Manage Widgets/1.0/buyWidgets operation.

5. Click OK.


Partner can Initiate: Override Inbound Settings

1. Click the operation Manage Widgets/1.0/buyWidgets in the panel Partner can initiate.


Transports Tab 3. Configure transport settings using Table 6.

4. Click Save.

This creates an operation binding for the operation buyWidget that will override any incoming request for this operation.

The same binding is used for the outgoing response for this request; for example, if you want to override the schema validation for an outgoing response, you can select the desired value in the Operation Settings tab for this binding.


Field Description

Allow All Operations Clear the checkbox for this tutorial.


Select the checkbox for this tutorial.

Table 6 Override Inbound Settings: Transports Tab

Field Description

Override Transports

Select the checkbox for this tutorial.


Primary Transport For this tutorial, select HTTP.



Configuring the Private Processes

This section describes how to configure the private processes on the Initiator and Responder machines.

Open the BusinessWorks ProjectTo open the example TIBCO ActiveMatrix BusinessWorks project in TIBCO Designer, do the following:

1. Start TIBCO Designer.

2. Click New empty project.

3. In the Save Project dialog, click Cancel.

4. Select Project>Import Full Project.

5. Click the ZIP Archive tab.

6. Navigate to //BC_home/samples/EZComm/tutorial

For Windows: C:\tibco\bc\n.n\samples\EZComm\tutorial

Click Yes.

7. Select EZComm.zip.

8. Click Open and OK.

9. In the Options tab, select the Try rename in case of name conflict radio button.

10. Click Apply.

11. Select Project>Save As.

12. In the Project Directory file chooser, navigate to a folder where you want to save the sample project.

13. Click OK.

14. Open the project by clicking on the (+) signs next to the project elements.

The window similar to the one shown in Figure 2 will display.

If you want to be able to restore the project for later use, be sure to select a directory other than BC_installation_directory\samples\EZComm\tutorial.

If your select the directory BC_installation_directory\samples\EZComm\tutorial, the zip archive file will be deleted.


Configuring the Private Processes | 23

Figure 2 TIBCO Designer: BusinessWorks Project

Configure Connections to Initiator TIBCO BusinessCo nnectTo configure connections to TIBCO BusinessConnect on the Initiator machine, do the following:

1. In the expanded project tree, double-click the Initiator TIBCO BusinessConnect connection icon .

2. Click the TIBCO BusinessConnect Server Access tab.



Figure 3 BusinessConnect Server Access Tab

a. Select the JDBC driver you use to communicate with the TIBCO BusinessConnect configuration store from the JDBC Driver dropdown list.

b. Type the URL for the configuration store in the JDBC URL field.

c. Type the configuration store user name and password in the DB User and Password fields.

d. Click the Apply button.

3. Click the Configuration tab.

4. Click the Update from Configuration Store button.

5. Select EZComm on the Protocol Name dropdown list .

6. If you select the checkbox Select Operations, you will be allowed to select any of the configured/imported operations

For this tutorial, select all operations and click OK.

7. In the dialog Confirmation on importing 'EZComm' operations, click Yes for Maintenance on EZComm Schemas

8. Click the Import Selected Business Protocol button.

The INIATOR (BusinessConnect Connection) screen appears.


Configuring the Private Processes | 25

Figure 4 INITIATOR (BusinessConnect Connection)

In the Imported Operations field, you will see the operations that you have imported in Import the Tutorial.

When you import the protocol, BusinessWorks retrieves information from the TIBCO BusinessConnect configuration store and puts it in the project folder.

9. Click Apply.

10. Click the Save icon to save the project.

Configure Connections to Responder TIBCO BusinessCo nnectOn the Responder machine, complete all steps explained in Configure Connections to Initiator TIBCO BusinessConnect, replacing all instances of Initiator with Responder.



Running the Tutorial

In order to see the complete tutorial for the Asynchronous Request Response operation, you have to run it on both machines, Buyer and Seller.

Run the Tutorial on the Seller Machine1. Using TIBCO Designer, select Projects and then the Receive Async Request

process under Responder/Asynchronous Request Response.

2. Select the Read File >Input Tab >ReadActivityInput and verify that the path given in the filename field is valid.

3. Select the Tester tab.

4. Click on the green triangle next to the icon Jobs.

The Select Process to Load dialog appears.

Figure 5 Select Process to Load

5. Select the Receive Async Request process under Responder/Asynchronous Request Response.

You can also run the Synchronous Request Response and Notify transactions using the processes provided in this tutorial.


Running the Tutorial | 27

6. Click Load Selected.

Once the request is received from the Buyer machine, this process will receive the message RESPODER.REQUEST and then send the message RESPONDER.RESPONSE to TIBCO BusinessConnect.

Run the Tutorial on the Buyer Machine1. In TIBCO Designer, select Projects and then the operation Send ASync

Request under INITIATOR/Asynchronous Request Response.

2. Click on SendRequest in the operation panel.

Figure 6 SendRequest (Input)

3. Be sure to enter “Buyer” in the field fromTP and “Seller” in the field toTP under the Input Tab, as shown inFigure 6.

4. Select Read File >Input Tab >ReadActivityInput and verify that the path given in the filename field is valid.

5. Click Apply and Save.



6. Select the Tester tab.

7. Select two processes:

— INITIATOR/Asynchronous Request Response/Send Async Request

— INITIATOR/Asynchronous Request Response/Receive Response processes.

8. Click Load selected.

9. In the Tester window, select the operation Send ASyncRequest and click on the Create Job button.

Figure 7 Create Job for the Send ASyncRequest operation

10. This will send an INITIATOR.REQUEST to the INITIATOR TIBCO BusinessConnect. At the same time, the Receive Response activity will receive the INITIATOR.RESPONSE message.

Figure 8 Send INITIATOR.REQUEST and Receive INITIATOR.RESPONSE



Figure 9 Send Async Request

Figure 10 RESPONDER AsynchronousRequestResoponse Process



View the Logs

On the Buyer Machine

1. In TIBCO Administrator select BusinessConnect>Log Viewer>Audit Logs

2. Select the protocol, host and status of the log, such as ANY.

The complete audit log for the Buyer machine is displayed.

Figure 11 Audit Log for the Buyer Machine



On the Seller Machine

1. In TIBCO Administrator select BusinessConnect>Log Viewer>Audit Logs

2. Select the protocol, host and status of the log, such as ANY.

The complete audit log for the Seller machine is displayed.

Figure 12 Audit Log for the Seller Machine


| 33

Chapter 3 EZComm URIs

This chapter provides more detailed information about the EZComm URIs.

Topics

• Exchanging URIs, page 34

• Populating URIs, page 37


34 | Chapter 3 EZComm URIs

Exchanging URIs

Partners must exchange Uniform Resource Identifiers (URIs) as part of the business agreement before they can transact e-commerce.

For EZComm, the URI, the subject, and the headers can encode information about the from trading partner, to trading partner, and the operation ID of the transaction. For an outgoing HTTP message, Business Connect always populates these values in an HTTP URL. However, for an incoming HTTP message it can interpret these values from an HTTP header or an HTTP URL, in that order.

Additional information in the URI, such as toTP and fromTP, is available only for transports other than AS1, AS2, or EMAIL, since the same information is derived from the internet headers such as AS2 TO/FROM ID and the EMAIL FROM/TO address. Such information becomes redundant and ambiguous if provided in the URI.

Available transports and their URI formats are listed in this section.

Email TransportThe URI format is mailto://username@domain, such as mailto://[email protected]

When using Email transport, you have the option of specifying the mail subject. If the subject contains the string operationID=”category/version_number/operation_name” then OperationID is taken as the operation ID for that transaction.

If the operation ID is not specified in the subject, then the value defaults to BC/version/Notify.

File TransportThe URI format is file://BaseDir/*.*

EZComm populates trading partner and operation information in the outgoing URI only if the URI ends with /EZComm.

While in TIBCO BusinessConnect EZComm Protocol 5.1 the only allowed value in an email subject was operationID=<opID>, release 5.3 allows any value to be specified in the subject: the operationID and other required values will be appended to the subject.


Exchanging URIs | 35

This causes all directories under BaseDir to be checked for files. In order for the file to be handled by EZComm, the document must appear as follows:

• Default behavior, such as for the operation BC/version/Notify:

BaseDir/EZComm/TpName

• Non-default behavior, for other operations:

BaseDir/EZComm/TpName/Category_OperationID

where BaseDir is a user selected base directory, TpName is the name of the trading partner, Category is the operation category, and OperationID is the operation ID.

If OperationID is not provided, then it defaults to BC/version/Notify.

You should provide a file mask *.* for a file. If you, for example, provide a file mask 101.xml, the file that is written out will be 101.xml. If you don’t provide a filer mask for a file, the file will not be picked up by the File transport.

FTP TransportURI format ftp://server:port/dir. dir can be anything or can be absent.

You should provide a file mask *.* for a file. If you, for example, provide a file mask 101.xml, the file that is written out will be 101.xml. If you don’t provide a filer mask for a file, the file will not be picked up by the FTP transport.

A file name can be specified in the file mask field. See TIBCO BusinessConnect Trading Partner Administration Guide, Table 41, Outbound File Transport for information on how to specify the file mask field in File transport.

A file name can be specified in the file mask field. See TIBCO BusinessConnect Trading Partner Administration Guide, Table 37, Inbound FTP/S Settings and Table 38, Outbound FTP/S Settings for information on how to specify the file mask field in FTP transport.

With EZComm, FTP inbound transactions always defaults to the BC/version/Notify operation.



HTTP/S Transport

URI for the HTTP Transport

URI format: http://server:port/EZComm

Example: http://www.gizmo.com:555/EZComm

For HTTP transport, the partner name, host name, and operation ID can be specified as parameters in the request URI or as transport headers.

The parameters or headers EZComm expects are as follows:

• fromTp This is a required field for the incoming message.

• toTp If this parameter is missing, it defaults to the default host.

• operationID If this parameter is missing, it defaults to BC/version_number/Notify.

• fileName If you specify the parameters in the URI, the format is: http://host:port/EZComm?fromTp=fromTP&toTp=toTP&operationID=opI

D&fileName=fileName

URI for the HTTPS Transport

URI format: https://server:port/EZComm

Example: https://www.gizmo.com:555/EZComm

The fileName feature is not supported for the AS2-HTTP transport.


Populating URIs | 37

Populating URIs

URIs are populated as follows:

• On the outbound side, URI fields have precedence over the headers. EZComm 5.3 populates the URIs with the required fields, such as fromTp, toTp, operationID, transactinID, and so on. If these fields are already specified in the GUI, they will be replaced.

This is a change in behavior from the release 5.1 , where the values specified in the GUI are not altered.

• EZComm 5.3 does not populate headers any more.

• On the inbound side, if values are specified in headers as well as URI places, the transport headers take precedence over the request URI values.

Special Handling for migrated EZComm 5.1 Operations

The operations migrated from EZComm 5.1 will have an Empty version number. In order to preserve the backward compatibility with EZComm 5.1, the values fromTp, toTp and others will be handled in the following way for the outbound messages:

• If the values are not specified in the GUI, they will be updated in the transport headers (same as in EZComm 5.1)

• URI precedence is still honored, but the values specified in GUI will be replaced with the current transaction values.

Specify Subjects

For the HTTP transport you also have the option of specifying the subject. If the subject contains a string operationID=”BC/Version/OperationID”, then BC/Version/OperationID is taken as the operationID for that transaction.

The precedence by which the operationID is determined is as follows: header, URI, and subject: header has the highest precedence and subject the lowest

The AS2 specification does not support custom headers.


| 39

Chapter 4 Managing EZComm Operations

This chapter describes how to manage the EZComm operations.

Topics


• Notify Operation, page 43

• Synchronous Request Response Operation, page 44

• Asynchronous Request Response Operation, page 45

• Configuring EZComm Operations, page 47


40 | Chapter 4 Managing EZComm Operations

Overview

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

• Public messages or operations

• Private messages. See EZComm Private Messages.

About EZComm OperationsPublic messages are exchanged over the Internet between TIBCO BusinessConnect and another B2B installation. The following message types are supported in TIBCO BusinessConnect EZComm Protocol:

• Notify Operation

• Synchronous Request Response Operation

• Asynchronous Request Response Operation

About Schema Validation in EZCommSchema validation in TIBCO BusinessConnect EZComm Protocol 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 will not observe any schema changes in the referenced object but you will 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 will be updated in the cache.

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


Overview | 41

Duplicate Message DetectionEZComm 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, TIBCO BusinessConnect creates a message digest from these predetermined fields and stores it 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 will be 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 will be notified by setting the duplicate field to true, while it is up to the private process to take further action.

Outbound Duplicate Detection Criteria

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

• TransactionID received from the user

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

• Trading partner host name

• Operation ID

• Host name

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

When the outbound File poller initiates a transaction, the transactionID will not be used for calculating the message digest.



Inbound Duplicate Detection Criteria

The following values from the incoming request will be 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 will be deleted.

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


Notify Operation | 43

Notify Operation

Notify is a one way operation: it can simply send a document to the trading partner and receive the acknowledgement. Its not capable of receiving the response from the trading partner.

The operation flow in a Notify operation is presented in Figure 13.

Figure 13 Notify Operation

The following process flow occurs with the Notify operation:

1. The Initiator private process sends a message to the Initiator TIBCO BusinessConnect.

2. The Initiator TIBCO BusinessConnect retrieves relevant information and sends the message to the Responder TIBCO BusinessConnect.

3. The Responder TIBCO BusinessConnect immediately sends a transport response (acknowledgment) to the Initiator TIBCO BusinessConnect on the same channel as the Initiator business request.

4. The Responder TIBCO BusinessConnect then forwards the message to the local private process.

See Responder Inbound Request — BusinessConnect to Private Process. The Responder TIBCO BusinessConnect considers the operation complete.

5. The Initiator TIBCO BusinessConnect sends an INITIATOR.RESPONSE message to the private process.

See Initiator Inbound Response — BusinessConnect to Private Process. This message is sent independently from the Responder TIBCO BusinessConnect, which sends a RESPONDER.REQUEST message to the Responder private process.

Supported Transports for the Notify Operation are: HTTP, HTTPS, HTTPSCA, File, FTP, FTPS, SSHFTP, Email, AS1, and AS2.

Responder

Private

Process

Responder

Request

ErrorError

Initiator

Request

Initiator

ResponseInitiator

BusinessConnect

Responder

BusinessConnect

InternetInitiator

Private

Process



Synchronous Request Response Operation

The Synchronous Request Response operation can send a document to the trading partner and wait for a response. It waits until the response is received and suspends any further processing for that request. This operation is used to send documents to trading partners and require response for further processing to proceed. The operation flow is presented in Figure 14.

Figure 14 Synchronous Request-Response Operation

1. The Initiator private process sends the request to the Initiator.

2. The Initiator sends the request to the Responder and waits for the response until the timeout specified in the appropriate transport has expired.

3. The Responder TIBCO BusinessConnect sends the request to the Responder private process.

4. The Responder private process send a response. If the private process doesn't respond on time, the Responder TIBCO BusinessConnect times out and ends the transaction. If the response from the private process arrives after this time out, the message will be rejected and an error will be thrown.

5. The response is forwarded to the Initiator TIBCO BusinessConnect.

6. The Responder acknowledgement will be sent to the private process indicating whether the response has been forwarded to the trading partner. It doesn't indicate whether the trading partner has received it or not.

7. Upon receiving the response from the Responder, the Initiator sends the Initiator Response message. If the Initiator times out, an audit log entry is generated, a timeout error advisory is sent, and the connection is closed.

Supported transports are: HTTP, HTTPS, and HTTPSCA.

Responder

Private

Process

Responder

Request Responder

ResponseInitiator

Request

Initiator

ResponseInitiator

BusinessConnect

Responder

BusinessConnect

Internet

Initiator

Private

Process

Responder

Acknowledgement

1

7

2

5

3

6

4

Resending of Responder.Request and Responder.Response for the Synchronous Request Response operation is not supported for EZComm.


Asynchronous Request Response Operation | 45

Asynchronous Request Response Operation

The asynchronous Request Response operation can send a document to the trading partner and wait for a response. It allows further processing, irrespective of the arrival of the response from the partner.

Figure 15 shows what happens when you run an asynchronous Request Response operation.

Figure 15 Tutorial: Asynchronous Request Response Operation

The following process flow occurs:

1. The Initiator private process sends a request to the Initiator TIBCO BusinessConnect.

2. The Initiator TIBCO BusinessConnect sends the request to the Responder and waits for the response until the timeout specified in the operation has expired.

3. The Responder TIBCO BusinessConnect sends a request to the Responder private process.

4. The Responder private process sends the response. If the private process doesn't respond on time, the Responder TIBCO BusinessConnect will time out and end the transaction.

If the response from the Responder private process arrives after the timeout, the message will be rejected and an error advisory will be sent.

5. If the response from Responder private process is received on time, the response is forwarded to the Initiator TIBCO BusinessConnect.

6. A Responder acknowledgement will be sent to the Responder private process indicating whether the response has been forwarded to the trading partner.

7. After receiving the response from the Responder, the Initiator will send the Initiator Response message.

Responder

Private

Process

Responder

Request Responder

ResponseInitiator

Request

Initiator

ResponseInitiator

BusinessConnect

Responder

BusinessConnect

Internet

Initiator

Private

Process

Responder

Acknowledgement

1

7

2

5

3

6

4



If the Initiator TIBCO BusinessConnect times out, an audit log entry will be generated and a timeout error advisory will be sent out. In this case, the request will be cancelled. When the response arrives at a later time, there won’t be any corresponding request present, the advisory will be rejected, an error advisory will be published, and an internal system error will be sent to the partner.

Supported transports are: HTTP, HTTPS, HTTPSCA, AS2_HTTP, Email, and AS1_EMAIL.

Resending of Responder.Response is not supported for the asynchronous Request Response operation.

Resending of Responder.Request is supported for the asynchronous Request Response operation. It can generate a response from the private process that will not be sent to the trading partner. In this case, a proper error message and an audit log will be generated.


Configuring EZComm Operations | 47

Configuring EZComm Operations

To configure an EZComm operation, perform these steps:

1. In the left panel under TIBCO BusinessConnect, click the link Operations Editor.

2. Select EZComm from the Protocol dropdown list.

Since EZComm gets installed with TIBCO BusinessConnect, it is always available on this list. Any other protocol must be installed first.

3. Click Edit.

The Edit Operations: EZComm dialog appears.

Figure 16 Configure New Operation for EZComm

Add New CategoryCategory is used to group operations based on their type.

1. Select the radio button associated with EZComm.

2. Click New Category.

3. In the New Category dialog, do the following:

— In the Name field, type a category name (required)

— In the Description field, type a brief description for this category (optional).

4. Click Save.



Add New VersionVersion is used to allow various subgroups of operations, such as Notify only, or Notify and Synchronous Request Response, and so on.

1. With the radio button for the new category selected, click New Version.

2. In the New Version dialog, do the following:

— In the Name field, type a version name (required)

— In the Description field, type a brief description for this version (optional).

3. Click Save.

Add New OperationOperations are added to a specific version. Each version can contain same or different operation sets.

1. With the radio button for the new version selected, click New Operation.

The New Operation dialog appears.

Figure 17 New Operation Dialog

2. Select one operation from the Operation Type dropdown list.

3. Click OK.

To configure an EZComm 5.3 operation for exchanging documents with an existing EZComm 5.1 system, which does not use the version subgroups for identifying an operation, specify the reserved version Empty for interoperability. At runtime, the reserved Empty version will be omitted when generating the operation ID identifier for the public message.

For example, MyCategory/Empty/MyOperation will be converted into MyCategory/MyOperation on the public message to interoperate with the EZComm 5.1 system.



The Operation dialog appears with the following tabs:

— Operation Tab

— Request Action Tab

— Response Action Tab

Operation Tab

In the Operation tab, enter information according to Table 7.

Table 7 Operation Tab

Click Save.

Field Enter/Select

Name Name of the operation (required)

Description Brief description for the operation

Inbound

Validate Message When selected, any inbound message (either request or response), will be validated. This should be selected if the Initiator needs the response from the partner to be validated, if the Responder needs the request to be validated.

Publish tibXML Private Process Message

If selected, the Responder private process will receive the message in tibXML format.

Note This flag is used only for the Responder, which means that only the ResponderRequest message will be published based on this flag.

Outbound

Validate Message When selected, either the request or response will be validated.

This checkbox should be selected in the following cases:

• Initiator needs that the request to the partner be validated

• Responder needs that the response be validated



Request Action Tab

In the Request Action tab, enter information according to Table 8.

Table 8 Request Action Tab

Field Enter/Select

Name Name of the request action

Description Brief description for the request action

Direction Initiator to Responder (pre-defined)

Validation Schema Name

Either XSD or DTD schema can be defined. File selected here should match the validation type selected in the field XML Document Validation.

To select the schema document:

1. Click on the change link.

2. In the Change File dialog, select one of the following two choice from the dropdown list:

• File Reference If you select file reference, enter the path to the .xsd file you wish to use.

• Uploaded File If you select uploaded file, the new Change File dialog will appear.

a. Click the Browse button and navigate to the directory containing the schema file. In this tutorial, it is located in the directory BC_home\samples\EZComm\sampleXML\xsd\

Select the schema document (101.xsd). This schema document is associated with the XML document used for validation (101.xml).

Note: EZComm supports XSD and DTD schema validation. In this tutorial, the XSD validation is used.

b. Click Open.

c. Click OK.

Require Digital Signature

Used only for HTTP transport. If selected, this option will sign the outgoing messages and force the incoming messages to be signed.

Require Content Encryption

Used only for HTTP transport. If selected, this option will encrypt the outgoing messages and force the incoming messages to be encrypted.



Click Save.

Response Action Tab

In the Edit Operation dialog, enter information according to Table 9.

Wait time for Response (seconds)

This field is available only for the asynchronous Request-Response operation.

The default is 3600 seconds.

For BC Palette use only

XML Document Validation

Select XSD or DTD from the dropdown list.

Root XML Element Name

Root XML element name, which is the top-level XML element in the document. It is only required if you are going to use the TIBCO BusinessConnect palette.

Table 8 Request Action Tab

Field Enter/Select

This tab is not available for the Notify operation.

Table 9 Response Action Tab: Synchronous and Asynchronous Request-Response Only

Field Enter/Select

Name Name of the response action

Description Brief description for the response action

Direction Responder to Initiator (pre-defined)

Validation Schema Name

Either XSD or DTD schema can be defined. File selected here should match the validation type selected in the field XML Document Validation.

For more information on how to select the schema document, see Validation Schema Name.


Used only for HTTP transport. If selected, this option will sign the outgoing messages and force the incoming messages to be signed.


Used only for HTTP transport. If selected, this option will encrypt the outgoing messages and force the incoming messages to be encrypted.



Click Save.

Private Process Wait (seconds)

Specifies the amount of time the Responder waits for the response from the private process.

The default is 3600 seconds (60 minutes).

For BC Palette use only

XML Document Validation

Select XSD or DTD from the dropdown list.

Root XML Element Name

Root XML element name, which is the top-level XML element in the document. It is only required if you are going to use the TIBCO BusinessConnect palette.

Table 9 Response Action Tab: Synchronous and Asynchronous Request-Response Only

Field Enter/Select


| 53

Chapter 5 Managing Properties

This chapter explains how to add and remove EZComm properties.

Topics

• Managing EZComm Properties, page 54


54 | Chapter 5 Managing Properties

Managing EZComm Properties

You can add, change, or remove EZComm properties using the Edit Plug-in Properties dialog.

Add a PropertyTo add a property, perform these steps:

1. In TIBCO Administrator, select TIBCO BusinessConnect>System Settings>Installed Protocols.

2. Select EZComm and then click Add.

3. Type a name for the property in the Property Name field.

4. Select a data type from the Property Type dropdown list: boolean, string. or integer.

5. Type a description of the new property in the Description field.

6. Click Save.

Delete a PropertyTo remove a property, perform these steps:

1. Select TIBCO BusinessConnect>System Settings>Installed Protocols.

2. Select EZComm and then click Delete.

3. Type the name of the property you want to delete and click OK.

Set Up the Property ezcomm.notify.email.preserveSub jectWhen sending email messages for EMAIL and AS1 transports, TIBCO BusinessConnect EZComm Protocol will generate the email subject based on operation and transaction IDs. However, it is possible to preserve the subject specified by the user on EMAIL and AS1 transports by enabling the EZComm property ezcomm.notify.email.preserveSubject. By setting this property to true, users can send their own email subject to trading partners.

Keep in mind that you may remove only user defined properties, and that default properties should not be removed.


Managing EZComm Properties | 55

The property ezcomm.notify.email.preserveSubject can be set as follows:

1. In TIBCO Administrator, select TIBCO BusinessConnect>System Settings>Installed Protocols.

2. Select EZComm plugin

3. Set true for the Boolean property ezcomm.notify.email.preserveSubject

4. Click Save.


56 | Chapter 5 Managing Properties


| 57

Chapter 6 Setting Up Trading Hosts and Partners

This chapter explains how to set up trading hosts and partners for TIBCO BusinessConnect EZComm Protocol.

Topics

• Configuring EZComm for a Host, page 58

• Configuring EZComm for a Partner, page 60


58 | Chapter 6 Setting Up Trading Hosts and Partners

Configuring EZComm for a Host

To configure the default host in a business agreement do the following:

Configure the Initiator Default Host1. Select BusinessConnect>Participants.


3. Type the host’s name in the Participant Name field.

4. Select Host in the Participant Type dropdown list.

5. Click Finish.

6. Click the host link.


8. Click Apply.

9. In the Edit Host Participant dialog, select the Protocols tab.

10. Click on the EZComm link.

Select or enter the information according to Table 10.

11. Click Save.

Table 10 Host Settings: General Tab

Field Description

AS2 Identifier) An identifier to use in the AS2-From header field of the HTTP message.

This identifier should be mutually agreed upon between trading partners.

For more information about AS2 Identifiers, see TIBCO BusinessConnect Server Administrator’s Guide, Disabling Session Cache for HTTPS.

Valid Email Address List

Enter the list of valid email addresses for this participant, separated by semicolon or by a comma.

For more details, see TIBCO BusinessConnect Trading Partner Administration Guide, Table 28, Configuring HTTP/S for a Trading Partner: General Tab.


Configuring EZComm for a Host | 59

Assign Default Host for Initiator1. Select BusinessConnect>System Settings in the left panel.

2. Click the General Settings link. The Edit System Settings: General Settings dialog appears.

3. Select the appropriate host in the Default Host dropdown list.

4. Click Save.



Configuring EZComm for a Partner

To configure a partner in a business agreement do the following:



3. Type partner’s name in the Participant Name field.


5. Click Finish.

Both the Buyer (Host) and Seller (Partner) now appear in the Participants panel.

6. Click the partner link.


8. Click Apply.

Enable Protocol for Initiator Partner1. In the Edit Partner Participant dialog, select the Protocols tab.

2. Click Enable.



4. Click OK.


5. Click on the EZComm link.

The Edit Enabled Protocol dialog appears, with the following tabs:

— General Tab

— Transports Tab


Configuring EZComm for a Partner | 61

General Tab

Select or enter information as explained in Table 11.

Click Save.

Table 11 Partner Settings: General Tab

Field Description

AS2 Identifier An identifier to use in the AS2-From header field of the HTTP message. This identifier should be mutually agreed upon between trading partners.

For more information about AS2 Identifiers, see TIBCO BusinessConnect Trading Partner Administration Guide, Disabling Session Cache for HTTPS.

Valid Email Address List

Enter the list of valid email addresses for this participant, separated by semicolon or by a comma.

For more details, see TIBCO BusinessConnect Trading Partner Administration Guide, Table 28, Configuring HTTP/S for a Trading Partner: General Tab.

Allow override of filename via HTTP parameter

If this checkbox is selected, and a file reference is being passed from the private process, then the name of the file is passed on to the Responder in an HTTP header called filename.

For more information, see Allow override of filename via HTTP parameter (applies only to HTTP/S transports).

Duplicate Detection for Outbound

If selected, all incoming private process messages and the outgoing responses are checked for duplicate detection.

If a request is found to be a duplicate, the transaction is terminated and an error advisory is sent.

Duplicate Detection for Inbound

All incoming requests for Responder and incoming responses for Initiator will be checked for duplicates.

If any duplicates are found, the duplicate field in the private process message will be set to true.

Use tibXML Packaging

This option is used for forcing the packaging of the outbound public message to a tibXML public message format.

See Use tibXML Packaging for more information.



Transports Tab

To add a transport for the partner, do the following:

1. Click on the Transports tab.

2. Click Add.

Enter data for the new transport as explained in Table 1.

3. Click OK.

Define URL

To define the URL for the partner, enter the following information:

URL (required): www.hostname:6700/EZComm.

Table 12 New Transport for the Partner

Field Description

Transport Name Enter the name for the transport (required)

Transport Type Select the transport type from the dropdown list.

To configure a specific transport for the partner, see TIBCO BusinessConnect Trading Partner Administration Guide, and then refer to the appropriate chapter for the transport such as:

• Chapter 10, HTTP, HTTPS, and HTTPSCA Transports

• Chapter 13, Email Transport

• Chapter 14, FTP and FTPS Transports

• Chapter 15, SSHFTP Transport

• Chapter 16, File Transport


| 63

Chapter 7 Configuring Business Agreements

This chapter explains how to configure business agreements and protocol bindings for TIBCO BusinessConnect EZComm Protocol.

Topics

• Adding a New Business Agreement, page 64

• Configuring Agreement Protocol Binding for EZComm, page 65

• Operation Bindings Tab, page 66

• Document Security Tab, page 71

• Transports Tab, page 72

• Show Advanced Tab on page 73


64 | Chapter 7 Configuring Business Agreements

Adding a New Business Agreement

After both trading partners are configured, you will now configure their business agreement.




Verify that EZComm appears in the Protocols column for both trading partners between which you wish to configure a business agreement. If EZComm is missing, return back to Enable Protocol for Initiator Partner and enable the EZComm protocol.

3. Select a host from the Host Party list.

4. Select a partner from the Partner Party list

5. Click OK.

The New Agreement, general dialog appears.


If you wish to make the agreement valid for a certain time period, do the following:

— Use the Start Date dropdown lists to specify the start date.

— Use the End Date dropdown lists to specify the stop date. This date has to be later than the start date.


Configuring Agreement Protocol Binding for EZComm | 65

Configuring Agreement Protocol Binding for EZComm

To configure EZComm agreement protocol bindings, follow these steps:

1. In the New Agreement dialog, click Add Protocol Bindings.

2. In the Select Protocol dialog, select the checkmark next to EZComm.

3. Click OK.


4. Click the EZComm link in the Agreement Protocol Binding list.

The following tabs for configuring protocol binding options are available:

— Operation Bindings Tab

— Document Security Tab

— Transports Tab

— Show Advanced Tab



Operation Bindings Tab

Use the Operations Binding tab to configure the EZCOmm operations that each participant in a business agreement can initiate and respond to.

The Host ’X’ Can Initiate and Partner ’Y’ Can Initiate areas list the activities that the host/partner can initiate and the partner/host can respond to.


2. In the Host can initiate section, click Add Operation Binding.

3. Click the topmost (+) to expand the operation tree and select the operation.

4. Click OK.


Edit Operation Bindings for the HostClick the operation in the panel Host can initiate.

The following tabs for configuring options are available:

• Operation Settings Tab

• Action Settings Tab.

• Transports Tab


Field Description

Allow All Operations

This checkbox is selected by default. If you leave it selected, you don’t need to specify operation bindings that the host or partner can initiate, as explained in Enter information according to Table 3..

If the checkbox is cleared, you need to define the specific operation bindings, as explained in Enter information according to Table 3..


The non-repudiation log is used to provide proof of the delivery of messages.

For more details, see TIBCO BusinessConnect Concepts, Non-Repudiation.


Operation Bindings Tab | 67

Operation Settings Tab

Override the operation settings using Table 14.

Click Save or Cancel (if no changes have been made).

Table 14 Override Outbound Settings: Operation Settings Tab (All Operations)

Field Description

Override Operation Settings

Select the checkbox to override the operation settings for this operation. These settings have been previously configured, as explained in Import the Tutorial.

Note When a BusinessConnect sever acts as the Initiator, the transport for sending an outbound document can be overridden for all operation types bound in this section.

Such overriding does not apply to the outbound responses of an Asynchronous Request Response operation in cases when the BusinessConnect server acts as the Responder.

Inbound

Validate Message When selected, an inbound message (either request or response) will be validated. This should be selected if the Initiator needs the response from the partner to be validated, if the Responder needs the request to be validated.


If selected, private process on the Responder side will receive the message in tibXML format. See Publish tibXML Private Process Messages for more information.

Outbound







Action Settings Tab.

Override the action settings using Table 15.


Transports Tab

Configure transport settings using Table 16.


Table 15 Override Outbound Settings: Actions Tab (Notify and Asynchronous Request-Response Operations)

Field Description

Override Action Settings

Select to override the originally configured action settings for the host.


(Notify operation only)

Select to override the originally configured signature settings for the host.



Select to override the originally configured encryption settings for the host.

tibXML Passthrough


Used to replicate the tibXML passthrough feature in EZComm. See tibXML Passthrough for more information.

Wait Time for Response (seconds)

(Asynchronous Request-Response operation only)

Select to override the originally configured Wait time for the Initiator. The default is 3600 seconds (60 minutes).

Table 16 Override Outbound Settings: Transports Tab (All Operations)

Field Description

Override Transports

Select to override the originally configured transport for the host.


Primary Transport Select any of the transports previously configured for the partner.

See Add Transport for Initiator Partner for more details.


Operation Bindings Tab | 69

Edit Operation Bindings for a Partner

Click the operation in the panel Partner can initiate.

The following tabs for configuring options are available:

• Operation Settings Tab

• Action Settings Tab

• Transports Tab

Operation Settings Tab

Override the operation settings using Table 17.


When a BusinessConnect sever acts as the Responder, the transport for sending an outbound document can only be overridden when sending the response for asynchronous operation types bound in this section.

Table 17 Override Inbound Settings: Operation Settings Tab (All Operations)

Field Description

Override Operation Settings

Select the checkbox to override the operation settings for this operation. These settings have been previously configured, as explained in Import the Tutorial.

Inbound

Validate Message When selected, an inbound message (either request or response) will be validated. This should be selected if the Initiator needs the response from the partner to be validated, if the Responder needs the request to be validated.


If selected, private process on the responder side will receive the message in tibXML format. See Publish tibXML Private Process Messages for more information.

Outbound







Action Settings Tab

To configure either the Synchronous or Asynchronous Request Response operation, click on the Action Settings tab and override the action settings using Table 18.


Transports Tab

Override transport settings using Table 19.


Table 18 Override Inbound Settings: Actions Tab (Synchronous and Asynchronous Request Response)

Field Description

Override Action Settings

Select to override the originally configured action settings for the partner.

Private Process Wait (seconds)

Select to override the originally configured Wait time (amount of time the Responder waits for the response from the private process).

The default is 3600 seconds (60 minutes).

Table 19 Override Inbound Settings: Transports Tab (All Operations)

Field Description

Override Transports

Select to override the originally configured transport for the partner.

Note For the Synchronous Request Response operation, this option is invalid.


Primary Transport

Select any of the transports previously configured for the partner.


Document Security Tab | 71

Document Security Tab

To learn about this topic, see TIBCO BusinessConnect Trading Partner Administration Guide, Document Security Tab.

See also TIBCO BusinessConnect Concepts, Chapter 8, Security.

Shadow Credential Usage for EZComm

Sending Signed or Encrypted Messages

When sending signed or encrypted messages over HTTP, HTTPS, or HTTPSCA transports, you will use shadow credentials during overlay and shadow credential period to sign or encrypt these messages.

Receiving Signed or Encrypted Messages

When receiving signed or encrypted messages from a trading partner over HTTP, HTTPS, or HTTPSCA transports, credentials are picked during the overlay period in the following order:

a. Shadow credential is tried for authentication or decryption

b. If this fails, the original credential is tried.

For the shadow credential period, only the shadow credential is tried.



Transports Tab

The Transports tab is divided in two sections as follows:

• The top section is used for specifying transport information for the outbound, or host to trading partner, direction.

• The bottom section is used for specifying transport information for the inbound, or trading partner to host, direction.

Configure transports for the host according to Table 20.

Click Save twice.

Table 20 Configure Transports for the Host

Field Description

Outbound Transports for Host

Primary Transport Select the outbound transport that was previously configured.

See Add Transport for Initiator Partner for more details.

AS2 MDN Async Reply Transport

Select any of the configured transports.

For more information, see TIBCO BusinessConnect Trading Partner Administration Guide, Table 7, Edit Protocol Bindings: Transports Tab.

AS2 Remote Server Certificate


Client Authentication Identity for HTTPS, FTPS, HTTPS CA


Client Authentication Identity for SSHFTP


Allowed Inbound Transports for Partner

(list of configured partner transports)

Select the appropriate checkboxes to allow certain inbound transports for the partner.


Show Advanced Tab | 73

Show Advanced Tab

The Show Advanced button in the Edit Protocol Bindings dialog allows you to configure additional settings for the host in a business agreement.

1. Click on Show Advanced.

The Edit Protocol Bindings dialog appears with two additional tabs: Host’s Configuration and Partner’s Configuration.

2. To hide the Host’s and Partner’s Configuration tabs, click the button Hide Advanced.

Override Settings for the HostTo override general settings for the host, do the following:

1. Select the tab representing the host.

2. Enter or select information according to Table 21.

3. Click Save.

Table 21 Edit Protocol Bindings: Advanced Settings for Host

Field Description

Override Settings If you select the checkbox Override Settings, this will override the values set on the host level: the AS2 Identity selected on the AS2 Identifier dropdown list will be used to override the default AS2 identity for the host configured using the procedure described in the following sections:

• TIBCO BusinessConnect Trading Partner Administration Guide, Set the Host’s AS2 Identifier for a Protocol

• TIBCO BusinessConnect Trading Partner Administration Guide, Disabling Session Cache for HTTPS

If you don’t select the checkbox Override Settings, the default AS2 identity for the host will remain valid.

AS2 Identifier Select an AS2 identity that will be used to override the default AS2 identity.



Override Settings for the PartnerTo override general settings for the partner, do the following:

1. Select the tab representing the partner.

2. Enter or select information according to Table 22.

3. Click Save.

Table 22 Edit Protocol Binding: Advanced Settings for Partner

Field Description

Override Settings If you select the checkbox Override Settings, this will override the values set on the partner level: the AS2 Identity selected on the AS2 Identifier dropdown list will be used to override the default AS2 identity for the host configured using the procedure described in the following sections:

• TIBCO BusinessConnect Trading Partner Administration Guide, Set the Host’s AS2 Identifier for a Protocol

• TIBCO BusinessConnect Trading Partner Administration Guide, Disabling Session Cache for HTTPS

If you don’t select the checkbox Override Settings, the default AS2 identity for the partner will remain valid.

AS2 Identifier Select an AS2 identity that will be used to override the default AS2 identity.

Allow override of filename via HTTP parameter(applies only to HTTP/S transports)

If this checkbox is selected, and a file reference is being passed from the private process, then the name of the file is passed on to the Responder in an HTTP header called filename.

Each partner has this checkbox. If it is selected and there is a fileName field in the HTTP message header or in QueryString (in that order), the message will be written to a file fileName. This file is created in the shared directory located under the partner’s name directory. The file size is irrelevant in this case.

Note This feature is fully supported for the Notify and Asynchronous Request Response operations. For the Synchronous Request Response operations, only request can send the filename to the partner while the partner cannot send the filename on the response: a synchronous response cannot be written to the file that the partner wants.

Use tibXML Packaging

This option is used for forcing the packaging of the outbound public message to a tibXML public message format.

See Use tibXML Packaging for more information.


| 75

Chapter 8 EZComm Private Messages

This chapter describes how to configure the EZComm private messages.

Topics


• Initiator Messages, page 77

• Responder Messages, page 81

• General Messages, page 86

• Multiple Attachments, page 87


76 | Chapter 8 EZComm Private Messages

Overview

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

• Private messages

• Public messages See Managing EZComm Operations

About EZComm Private MessagesPrivate messages are exchanged between a private process and the local TIBCO BusinessConnect installation. Private messages can contain a request, response, or notification document. The private process handles conversion from internal to public data and back.

• On the Initiator side, the private process converts internal data to an EZComm notification document.

• On the Responder side, the private process receives an EZComm request and converts it to internal company format.

You can generate EZComm private messages from TIBCO ActiveMatrix BusinessWorks private processes that use the TIBCO BusinessConnect Palette.

The TIBCO BusinessConnect server has two major roles:

• Initiator This role receives request messages from private processes and transmits the EZComm documents to your trading partners.

• Responder This role receives EZComm documents from trading partners and submits the converted request messages to their private processes.

The following sections describe the messages used for private request and response document exchange in TIBCO BusinessConnect EZComm Protocol. The message fields are packaged in the ^data^ control tag as part of the aeRvMsg format.

See TIBCO BusinessConnect Trading Partner Administration Guide, Chapter 7, Private Process Configuration for more information.


Initiator Messages | 77

Initiator Messages

Initiator Outbound Request — Private Process to TIB CO BusinessConnect

The Initiator private process uses this message to handle outbound requests. Data that is sent is in a string or in binary form.

Subject Name prefix.installation.EZComm.INITIATOR.REQUEST

External example: AX.BC.BC-ACME.EZComm.INITIATOR.REQUEST

If both plainRequest and inputFile are passed, the plainRequest node will be used.

If both binaryRequest and inputFile are passed, the binaryRequest node will be used.

Table 23 Private Message: InitiatorRequest

Field Type Required Description

fromTp String No Name of the trading partner initiating the transaction

toTp String Yes Name of the trading partner receiving the transaction

operationID String No A three-part ID of the form: category/version_number/operation_Name

transactionID String Yes An ID unique within Initiator private processes environment for this transaction. The private process creates this ID.

closure String No The private process generates the closure message and sends it to TIBCO BusinessConnect, which is required to return this closure contents back in the InitiatorResponse to ensure that the private process can match it with the original Initiator.Request.

binaryRequest base64Binary

No Private processes use the binaryRequest field to send binary data to TIBCO BusinessConnect.

content-type String No Content type of the passed data



content-dispos

itionString No Maps to MIME's content-disposition. This value, if

provided, will be set in the MIME Internet headers.

inputFile String No If a file reference is being passed to TIBCO BusinessConnect, this field is used.

Attachment

name String No Name of the attachment file.


content Base64Binary

No Content for the attachment.

fileName String No A file reference can be sent as an attachment.


deleteFile Boolean No If set to true, the file reference specified in the filename field will be deleted after the completion (successful or otherwise) of the transaction processing.

content-id String No Represents the content Id for the attachment. It must be specified and enforcement is performed at the BusinessWorks palette level.

If this field is not specified, it will be populated as transactionID-sequence number.

content-type String No Represents the content type of the message content.


Table 23 Private Message: InitiatorRequest (Cont’d)



Initiator Messages | 79

Initiator Inbound Response — BusinessConnect to Priv ate Process

The Initiator private process uses this message to handle inbound responses.

Subject Name prefix.installation.EZComm.INITIATOR.RESPONSE

External example: AX.BC.ACME.EZComm.INITIATOR.RESPONSE

Table 24 Private Message: InitiatorResponse


standardID String Yes Protocol name

fromTp String No Name of the trading partner initiating the transaction

toTp String Yes Name of the trading partner receiving the transaction


transactionID String No An ID unique within Initiator private processes environment for this transaction. The private process creates this ID.

statusCode String No Code indicating the status of the message. 200 for success. Otherwise, a code that represents the type of error.

statusMsg String No OK or a description of the cause of the error

closure String No The private process generates the closure message and sends it to TIBCO BusinessConnect. TIBCO BusinessConnect is required to return this closure contents back in the InitiatorResponse to ensure that the private process can match it with the original InitiatorRequest.

duplicate Boolean No Specifies whether the incoming response is a duplicate.

binaryResponse String Response is sent to this field if it contains binary data.

responseFile String No File name containing the response



originalFileName String No This field contains the filename of the original request file; for example, for the File and FTP transports this is the actual filename that is in the directory or on the FTP server.

Attachment



content any No Content for the attachment.



deleteFile Boolean No If set to true, then the private process can decide to delete the inbound attachment file.

content-id String No Represents the content Id for the attachment. It must be specified and enforcement is performed at the BusinessWorks palette level. If this field is not specified, it will be populated as transactionID-sequence number.



Body

stringData

(plainResponse)

String No Response is sent to this field if it contains string data.

Table 24 Private Message: InitiatorResponse (Cont’d)



Responder Messages | 81

Responder Messages

Responder Inbound Request — BusinessConnect to Priv ate Process

The Responder private process uses this message to handle inbound requests..

Subject Name prefix.installation.EZComm.RESPONDER.REQUEST

External example: AX.BC.BC-ACME.EZComm.RESPONDER.REQUEST

Table 25 Private Message: ResponderRequest



fromTp String Yes Name of the trading partner who initiated the transaction

toTP String Yes Name of the trading partner who received the transaction


transactionID String Yes A unique ID generated by TIBCO BusinessConnect when publishing the transaction to the private process's environment.

closure String No A closure message generated by the private process and sent to TIBCO BusinessConnect

binaryRequest base64Binary

No Used by TIBCO BusinessConnect to send data when binary data is being passed to a partner.

isBinaryFile Boolean No This field shows whether the file specified in the field inputFile is a binary file.

inputFile String No Used for a file reference that was passed to TIBCO BusinessConnect.

operationType String No Represents the type of the operation, such as Notify, Synchronous Request Response, or Asynchronous Request Response.



duplicate Boolean No Specifies whether the incoming request is a duplicate.

originalFileName String No This field contains the filename of the original request file; for example, for the File and FTP transports this is the actual filename that is in the directory or on the FTP server.

Attachment



content any No Content for the attachment.



deleteFile Boolean No If set to true, then the private process can decide to delete the inbound attachment file.




Table 25 Private Message: ResponderRequest (Cont’d)




Responder Outbound Response — Private Process to Bus inessConnect

The Responder private process uses this message to handle outbound responses..

Subject Name prefix.installation.EZComm.RESPONDER.RESPONSE

External example: AX.BC.BC-ACME.EZComm.RESPONDER.RESPONSE

Table 26 Private Message: Responder.Response


statusCode Integer Yes Code indicating the status of the message (200 for success). Otherwise, a code that represents the type of error.

statusMsg String Yes OK or a description of the cause of the error

binaryResponse Base64Binary

No Response is sent to this field if it contains binary data.

responseFile String No This is the name of the file that contains the response.

deleteResponseFile Boolean Deletes the response file if the value is true.

closure String Yes This is the closure that is received from the Responder Request Based on this value, this response is correlated to the request.

content-type String No Content type of the response. If not specified, TIBCO BusinessConnect will interpret this value.

content-disposit

ionString No Maps to MIME's content-disposition. This value, if

provided, will be set in the MIME Internet headers.

Attachment



content Any No Content for the attachment.





deleteFile Boolean No If set to true, the file reference specified in the filename field will be deleted after the completion (successful or otherwise) of the transaction processing.




Body

stringData

(plainResponse)

String No Response is sent to this field if it contains string data.

Table 26 Private Message: Responder.Response




Responder Acknowledgement — Private Process to Busi nessConnect

The Responder TIBCO BusinessConnect sends this acknowledgement after it receives the Responder Response. The acknowledgement indicates whether the Responder Response has been forwarded to the trading partner..

Subject Name prefix.installation.EZComm.RESPONDER.ACK

External example: AX.BC.BC-ACME.EZComm.RESPONDER.ACK

Table 27 Private Message: Responder.Ack


statusCode String Yes Code indicating the status of the message (200 for success). Otherwise, a code that represents the type of error.

statusMsg String Yes OK or a description of the cause of the error

operationType String No Represents the type of the operation. In this case it is ack, indicating that the message is of the type Acknowledgement.

closure String Yes A closure sent by the Responder Response message.



General Messages

Error Messages

TIBCO BusinessConnect uses the error message to publish status information.

Subject Name prefix.installation.EZComm.ERROR

Example: AX.BC.BC-ACME.EZComm.ERROR

Table 28 Private Message: Error Message


statusCode String No One of the private party-defined status and error codes

statusMsg String No The string representing the cause of one of the private party-defined status or error codes

details String No Additional information

msgDirection String No The flow of the message, either inbound or outbound

closure Reserved


transactionID String No A unique ID generated by TIBCO BusinessConnect when publishing the transaction to the private process's environment


timestamp String No Time stamp for this message

host String No Host name

tpName String No Trading partner name

extraInfo String No This field contains the originalFileName when available.

Body

stringData String No


Multiple Attachments | 87

Multiple Attachments

TIBCO BusinessConnect EZComm Protocol 5.3 allows you to send attachments to the trading partner. The current private process schema accommodates attachments so that the attachment field represents a sequence which allows any number of attachments to be specified.

The fields available for configuring an attachment are as follows:

• name This represents the name of the attachment. If none is specified, it will be named AttachmentsequenceNumber.second part of the content type.

For example, if you are sending an xml file, the content type will be text/xml and the attachment name will be Attachment0.xml. (1 is the sequence number for the first element of the attachment sequence).

• content Content of the attachment.

• fileName A file reference can be sent as an attachment. The content of this file will be read and set to the content of the attachment.

— If both the content and fileName fields are specified, then content will be set as the attachment data.

— If neither the content nor the fileName fields are specified, then this attachment element will not be processed.

Specifying of these fields is not enforced by the private process.

• deleteFile This is a Boolean field. If set to true, the file reference specified in the filename field will be deleted after the completion (successful or otherwise) of the transaction processing.

• contentID Represents the content Id for the attachment. It must be specified and enforcement is performed at the BusinessWorks palette level. If this field is not specified, it will be populated as transactionID-sequence number.

• contentType Represents the content type of the message content. If not specified, it will be inferred by the protocol.

If there is no contentType field specified, such as when neither content nor the fileName fields are specified, the attachment will not be processed.

EZComm writes an attachment to a file and sends the reference to the private process, with one exception: if the private process message is in the tibXML format, the attachment will be sent as part of the TIBCO Rendezvous message. Based on the content-type of the attachment, it will be populated either in the message type field STRING or OPAQUE.



Resending EZComm Private Process Messages

EZComm can resend the private process messages that are in audit states RECEIVED_FROM_PP and SEND_TO_PP.

Following is the relationship between the audit states and private process message types:

• On the Initiator side

RECEIVED_FROM_PP INITIATOR.REQUEST

SEND_TO_PP INITIATOR.RESPONSE

• On the Responder side

RECEIVED_FROM_PP RESPONDER.RESPONSE

SEND_TO_PP RESPONDER.REQUEST

The message RESPONDER.REQUEST is not resendable for the synchronous transactions: it is only resendable for the Notify and asynchronous transactions.

The message RESPONDER.RESPONSE is not resendable for any transaction type.

Once a message is sent in a particular format, such as tibXML or EZComm, the resent message will also be in the same format.

The configuration option “Publish tibXML Private Process Message” is not considered while resending the RESPONDER.REQUEST message. The original standard ID is always used when resending the private process message on the subject with the same protocol.


| 89

Chapter 9 Viewing Logs

This chapter explains the use of logs in EZComm.

Topics

• Audit Logs, page 90

• Non-Repudiation Logs, page 93

• Resend Logs, page 96


90 | Chapter 9 Viewing Logs

Audit Logs

The audit log is used to store information about the messages and documents processed by TIBCO BusinessConnect EZComm Protocol.

You can use the audit log to follow the processing states of inbound or outbound documents. Some of the types of information stored in the audit log include: sent and received documents; document originator; trading partner name; processing status; and validation errors.

For more information on audit logs, see TIBCO BusinessConnect Trading Partner Administration Guide, Audit Logs.

Configure an Audit Log for EZCommTo configure an audit log for EZComm, do the following:

1. Select BusinessConnect>Log Viewer>Audit Logs.

SearchTransactions

2. Configure transactions to search.

Table 29 lists the options to select in the Search Transactions section of the audit log.

The entire AESchema is stored in the fields REQUEST_FROM_PP and SEND_TO_PP fields in the audit log, since this is required for the resend.

When doing searches, remember that the character “*” is not considered to work as a wild card, but represents a part of a name.

TIBCO BusinessConnect EZComm Protocol does not record advisory messages, such as the Responder Acknowledgement, in the audit log.

Table 29 Audit Log: Search Transactions

Column Name Definition

Protocol Select a protocol (EZComm)

Connection Select a connection name

Host Select a specific host name or ANY


Audit Logs | 91

Audit Log:Advanced Search

Settings

3. Configure the advanced search settings.

Table 30 lists the options to select in the Advanced Search Section Settings section of the audit log.

Status Select a specific status, such as ANY, CANCELED, COMPLETED, ERROR, ERROR SECURITY,PENDING, or RECEIPT PENDING

Date Range Criteria

Select Custom Date Range or Predefined Date Range.

If Custom Date Range is selected, additional fields for defining exact dates will become available.

If Predefined Date Range is selected, the additional field Previous for defining the date range will become available. Previous predefined period can be One Day, One Week, One Month, or One Year.

Previous From this dropdown list, you can select the previous period to search:

• One Day

• One Week

• One Month

• One Year

Table 29 Audit Log: Search Transactions (Cont’d)


Table 30 Audit Log: Advanced Search Settings

Column Definition

Trading Partner Trading Partner name

Boolean search using: is, contains, is not, is not like

DocumentID Document ID (This is always a unique name)


User TranID The user transactionID column displays the transaction ID received from the private process on the Initiator side.

Initiator forwards this ID to the Responder and at the same displays it in this column. This way, a transaction initiated by the Initiator can be cross-referenced on the Responder side. This feature works only for HTTP/S and Email transports. For File and FTP/S transports, this column is left blank.




4. In addition to these search entry fields, here are also buttons available that allow you to do the following:

— Remove Query

— Execute Query

— Save Current Query

— Search

To learn more about these options, see TIBCO BusinessConnect Trading Partner Administration Guide, Saving and Reusing Queries.

Operation ID Operation ID


Host Initiates For the Initiator, this value will be true for any type of transaction (Notify , Synchronous Request Response, or Asynchronous Request Response). For the Responder, this value is always false.

This value is true for outgoing requests, while for incoming requests and for outgoing responses this value will be false.


Transaction Type Type of the transaction you are searching, which is important to differentiate since EZComm handles the tibXML messages.

The valid values for the field are as follows:

• EZComm-Notify (Notify operation for EZComm)

• EZComm-Async (Async operation for EZComm)

• EZComm-Sync (Sync operation for EZComm)

• tibXML-Notify (Notify operation for tibXML)

• tibXML_Async (Async operation for tibXML)

• tibXML-Sync (Sync operation for tibXML)

• tibXML-passthrough (Passthrough operation)


Table 30 Audit Log: Advanced Search Settings (Cont’d)

Column Definition


Non-Repudiation Logs | 93

Non-Repudiation Logs

The non-repudiation log is used to provide proof of the delivery of messages. Non-repudiation depends on authentication using digital signatures. Incoming messages which have been digitally signed are authenticated and stored in the non-repudiation database. Outbound messages that have been digitally signed are also stored in the database.

For more information on non-repudiation logs, see TIBCO BusinessConnect Concepts, Non-Repudiation.

Configure a Non-Repudiation Log for EZCommTo configure a non-repudiation log for EZComm, do the following:

1. Select BusinessConnect>Log Viewer>Non Repudiation Logs.

SearchTransactions

2. Configure transactions to search.

Table 31 lists the options to select in the Search Transactions section of the non-repudiation log.

Table 31 Non-Repudiation Log: Search Transactions


Protocol Select a protocol (EZComm)

Connection Select a connection name.

Host Select a specific host name or ANY.

Status Select a specific status, such as CANCELED, COMPLETED, ERROR, ERROR SECURITY, PENDING, or RECEIPT PENDING.

Date Range Criteria






Non-RepudiationLog: Advanced

Search Settings


Table 32 lists the options to select in the Advanced Search Section Settings section of the non-repudiation log.


• One Day

• One Week

• One Month

• One Year

Table 31 Non-Repudiation Log: Search Transactions (Cont’d)


Table 32 Non-Repudiation Log: Advanced Search Settings

Column Definition

Trading Partner Name of the Trading Partner


Document ID Document ID


Transaction Type Type of the transaction you are searching.




User TranID The user transactionID column displays the transaction ID received from the private process on the Initiator side.



Non-Repudiation Logs | 95

4. In addition to these search entry fields, there are also buttons available that allow you to do the following:

— Remove Query

— Execute Query

— Save Current Query

— Search

To learn more about these options, see TIBCO BusinessConnect Trading Partner Administration Guide, Saving and Reusing Queries.



Resend Logs

The resend log provides two views into the audit log:

• Resendable transactions Allows you to resend a transaction.

• Resend history Allows you to view messages that have been resent.

For more information about resend logs, see TIBCO BusinessConnect Trading Partner Administration Guide, Resend Logs.

Configure a Resend Log for EZCommTo configure a resend log for EZComm, do the following:

1. Select BusinessConnect>Log Viewer>Resend Logs.

There are two tabs available in the Resend Logs dialog: Resendable Transactions and Resend History.

Resendable Transactions Tab

SearchTransactions

2. Configure the search for resendable transactions.

For the state RECEIVED_FROM_PP, the Outbound File Poller messages cannot appear in the list of resendable transactions and therefore cannot be resent.

For the state SEND_TO_PP, the Outbound File Poller messages can appear in the list of resendable transactions.

The resendable transactions that are shown on the screen depend on the Private Processes that are configured.

If TIBCO Rendezvous (or JMS) is configured for Private Process communication, only the messages sent over or received from Rendezvous (or JMS) transport will be displayed.


Resend Logs | 97

Table 33 lists the options to select in the Search Transactions section of the resend log.

3. In addition to these search entry fields, here are also buttons available that allow you to do the following:

— Search (execute a search)

— Done (finish using the dialog)

To learn more about these options, see TIBCO BusinessConnect Trading Partner Administration Guide, Performing a Log Search.

Table 33 Resend Log: Resendable Transactions


Protocol Select a protocol.



Status Select a specific status, such as CANCELED, COMPLETED, ERROR, ERROR SECURITY, PENDING, or RECEIPT PENDING.

Date Range Criteria





• One Day

• One Week

• One Month

• One Year

State Select the transaction state: RECEIVED_FROM_PP or SEND_TO_PP



Resend Log:Advanced Search

Settings


Table 34 lists the options to select in the Advanced Search Section Settings section of the resend log.

Table 34 Resend Log: Advanced Search Settings

Column Definition

Trading Partner Boolean search using: is, contains, is not, is not like

Document ID Boolean search using: is, contains, is not, is not like

Transaction Type Boolean search using: is, contains, is not, is not like

Type of the transaction you are searching.



User TranID Boolean search using: is, contains, is not, is not like

The user transactionID column displays the transaction ID received from the private process on the Initiator side.

Initiator forwards this ID to the Responder and at the same displays it in this column. This way, a transaction initiated by the Initiator can be cross-referenced on the Responder side. This feature works only for HTTP/S and Email transports.

For File and FTP/S transports, this column is left blank.

Host Initiates Boolean search using: is, contains, is not, is not like

• For the Initiator, this field will be true for any type of transaction (Notify, Synchronous Request Response, or Asynchronous Request Response).

• For the Responder, it is always false.



Resend Logs | 99

Resend History Tab

SearchTransactions

5. Configure the search for resend history.

Table 35 lists the options to select in the Search Transactions section of the resend log.

Table 35 Resend Log: Resend History


Protocol Select a protocol.



Status Select a specific status, such as ANY, CANCELED, COMPLETED, ERROR, ERROR SECURITY, PENDING, or RECEIPT PENDING.

Date Range Criteria





• One Day

• One Week

• One Month

• One Year



Advanced SearchSettings


Table 36 lists the options to select in the Advanced Search Section Settings section of the resend log.

7. In addition to these search entry fields, there are also buttons available that allow you to do the following:

— Search (execute a search)

— Done (finish using the dialog)

To learn more about these options, see TIBCO BusinessConnect Trading Partner Administration Guide, Performing a Log Search.

Table 36 Resend Log: Advanced Search Settings

Column Definition

Trading Partner Boolean search using: is, contains, is not, is not like

Document ID Boolean search using: is, contains, is not, is not like

User TranID Boolean search using: is, contains, is not, is not like.

The user transactionID column displays the transaction ID received from the private process on the Initiator side.

Initiator forwards this ID to the Responder and at the same displays it in this column. This way, a transaction initiated by the Initiator can be cross-referenced on the Responder side. This feature works only for HTTP/S and Email transports.

For File and FTP/S transports, this column is left blank.



Host Initiates Boolean search using: is, contains, is not, is not like

• For the Initiator, this field will be true for any type of transaction (Notify , Synchronous Request Response, or Asynchronous Request Response).

• For the Responder, it is always false.


Transaction Type Boolean search using: is, contains, is not, is not like

Type of the transaction you are searching.


| 101

Chapter 10 File Pollers

This chapter explains outbound and inbound File pollers for EZComm.

Topics

• Outbound File Pollers for EZComm, page 102

• Inbound File Pollers for EZComm, page 103


102 | Chapter 10 File Pollers

Outbound File Pollers for EZComm

The outbound File poller provides a simple way for private processes to transmit documents to TIBCO BusinessConnect. This contrasts with the other transports, which are used for communication between trading partners.

Outbound File pollers are used by enterprises that do not wish to use TIBCO Rendezvous to transfer documents to TIBCO BusinessConnect.

URI Format for EZComm Outbound File Pollers

For the File transport, URI format is as follows: file://BaseDir/*.*

This causes all directories under BaseDir to be checked for files.

In order for the file to be handled by EZComm, the document must appear as follows:

• Default behavior, such as for the operation BC/1.0/Notify:

BaseDir/TpName

• Non-default behavior, for other operations:

BaseDir/TpName/Category_Version_OperationID

where

• BaseDir is a user selected base directory

• TpName is the name of the trading partner

• Category is the operation category

• Version is the operation version

• OperationID is the operation ID

If Category_Version_OperationID is not provided, then it defaults to BC/1.0/Notify.

Since the default operation has changed from BC/Notify to BC/1.0/Notify, files in the directory Category_operationID will be treated as Category_Empty_operationID; for example, TIBCO BusinessConnect will look for an operation Category/Empty/operationID in the configuration store. To read general information on how to enable an outbound File poller, see TIBCO BusinessConnect Trading Partner Administration Guide, Outbound File Pollers.

The sending partner for outbound File pollers is assumed to be the default host.


Inbound File Pollers for EZComm | 103

Inbound File Pollers for EZComm

When File outbound is used as a transport, the trading partner uses an inbound File poller to check for the documents.

To read general information on how to enable an inbound File poller, see TIBCO BusinessConnect Trading Partner Administration Guide, Inbound File Pollers.

For the inbound File pollers, the receiving partner is assumed to be the default host.


104 | Chapter 10 File Pollers


| 105

Chapter 11 tibXML Integration

The tibXML protocol users are now able to substitute it with the TIBCO BusinessConnect EZComm Protocol, which can work with projects generated using tibXML.

Topics


• New GUI Options for tibXML-to-EZComm Integration, page 108

• tibXML Private Process Messages, page 109

• Private Process Migration, page 128

• tibXML Public Messages, page 116

• MIME Message Packaging Options in tibXML, page 119

• Passthrough Mode in tibXML, page 120

• Setting Timing Restrictions in tibXML, page 121


106 | Chapter 11 tibXML Integration

Overview

TIBCO BusinessConnect tibXML Protocol is a business protocol developed by TIBCO for exchanging XML used in e-commerce. It allows buyers, sellers, and intermediaries to share business documents and messages over the Internet. tibXML can also be used for other types of supply chain integration transactions, such as collaborative forecasting, inventory management, and design collaboration.

TIBCO BusinessConnect EZComm Protocol 5.3 can do the following:

• Interoperate with the systems using the tibXML protocol and receive responses from these systems.

• Receive tibXML requests and send response in the tibXML format

• Interpret private process messages coming from the tibXML 3.x private processes as tibXML messages. If it receives such message, the response and any errors for the transaction will be published on tibXML subjects and in the tibXML format.

• It can be configured to send private process (Responder Request) messages in the tibXML format, which is enabled by selecting the checkbox Publish tibXML Private Process Message in the Operations Editor dialog under BusinessConnect>Operations Editor>EZComm><operation Type>>General.

TIBCO BusinessConnect EZComm 5.3 is backward compatible with the private process messages coming from any tibXML private process. It is assumed that these messages adhere to the schema provided by tibXML.

Two sample usage scenarios for using tibXML 3.6 and EZComm 5.3 on two systems is shown in Example Usage Scenarios for EZComm-to-tibXML Integration.


Overview | 107

Example Usage Scenarios for EZComm-to-tibXML Integr ationIn the first example, the Initiator is using TIBCO BusinessConnect 3.6 and the TIBCO BusinessConnect tibXML Protocol, while the Responder is using TIBCO BusinessConnect 5.3 and the TIBCO BusinessConnect EZComm Protocol.

Figure 18 Initiator Request: Initiator Using tibXML 3.x, Responder Using EZComm 5.3

In the second example, the Initiator is using TIBCO BusinessConnect 5.3 and the TIBCO BusinessConnect EZComm Protocol, while the Responder is using TIBCO BusinessConnect 3.6 and TIBCO BusinessConnect tibXML Protocol.

Figure 19 Initiator Request: Initiator Using EZComm 5.3, Responder Using tibXML 3.6

EZComm 5.3

Private

Process

Responder

Request

Responder

Response

Error

Initiator

Request

Initiator

Response

Initiator

BusinessConnect 3.6

Responder

BusinessConnect 5.3

InternettibXML 3.x

Private

Process

Public message format on both sides is tibXML

tibXML 3.x

Private

Process

Responder

Request

Responder

Response

Error

Initiator

Request

Initiator

Response

Initiator

BusinessConnect 5.3

Responder

BusinessConnect 3.6

InternetEZComm 5.3

Private

Process

Public message format on both sides is tibXML



New GUI Options for tibXML-to-EZComm Integration

There are three new fields in the EZComm GUI that facilitate tibXML-to-EZComm integration:

• Publish tibXML Private Process Messages

This option is available under BusinessConnect> EZComm><operation_name>>General as an operation property for inbound and allows the Responder to send tibXML private process messages.

• tibXML Passthrough

This option is available as an action property only for the Notify operation and enables it to send any XML or non-XML message resembling the Pass Through Message in tibXML.

When this checkbox is selected and when the outbound URL/subject contains tibXML, URL/subject is updated with tibXML-passthrough. For more information, see Passthrough Mode in tibXML.

• Use tibXML Packaging

This option is available in the dialog under BusinessConnect>Partner>EZComm->General. It is used for forcing the packaging of the outbound public message, when the URL suffix does not contain EZComm or tibXML, to a tibXML public message format; for example, a message with an additional MIME part that contains the element <header>.


tibXML Private Process Messages | 109

tibXML Private Process Messages

TIBCO BusinessConnect EZComm 5.3 looks for the standardID value of tibXML for all private process messages (INITIATOR.REQUEST and RESPONDER.RESPONSE) it receives. When the standardID is not present, it checks the subject or the RV message to determine the protocol.

If tibXML processing is found either in the standardID or in the subject field, the message will be interpreted as an tibXML private process message and TIBCO BusinessConnect will look for the tibXML aeschema for fetching the values from that message.

Rules for Handling tibXML MessagesBusinessConnect can send INITIATOR.RESPONSE, RESPONDER.REQUEST, RESPONDER.ACK, and ERROR.NOTIFY messages to the private process. Since TIBCO BusinessConnect EZComm can send these messages both in the EZComm and in tibXML format, the following criteria will be used to determine the private process message format.

Initiator Messages

When an INITITATOR.REQUEST arrives in tibXML message format, a message INITIATOR.RESPONSE is sent out in the tibXML message format. The subject will have tibXML as the protocol name. During this transaction, if there are any errors or advisories, they will be published in the tibXML message format.

Responder Messages

On the Responder side, a user must configure to send the messages in the tibXML format by selecting the option Publish tibXML Private Process Message on the operation tab. If the RESPONDER.REQUEST message is sent out on the tibXML subject in tibXML format, TIBCO BusinessConnect expects RESPONDER.RESPONSE in the tibXML format and sends the RESPONDER.ACK on the tibXML subject.

If any tibXML message (the message with a subject containing tibXML) contains EZComm in the field standardID, it will be treated as EZComm and will fail.



The configuration option “Publish tibXML Private Process Message” is not considered while resending the RESPONDER.REQUEST message because the resend log stores the original RESPONDER.REQUEST message that was sent. The original standard ID is always used when resending the private process message on the subject with the same protocol.

When you choose to resend this message, the original message is retrieved from the log and sent as is .



Connection Between tibXML Public and Private Proces s MessagesPrivate process messages do not depend on the public message format. TIBCO BusinessConnect can receive a tibXML private process message (or an EZComm message), yet it can send the public message to the trading partner in the EZComm format (or in the tibXML format, respectively).

BusinessConnect can receive a public message in the EZComm or in tibXML format and still be able to send the private process message based on the option Publish in tibXML Format selected by a user.

Transports for tibXML Private Process MessagestibXML has only TIBCO Rendezvous as a private process.

If the option Publish tibXML private process Messages is selected and the configured transport in TIBCO BusinessConnect EZComm Protocol is JMS, an error entry is made in the audit log and the transaction is terminated. No advisories will be published on the JMS transport.

This scenario occurs only when sending the messages on the Responder side, such as RESPONDER.REQUESt or error advisories. On the Initiator side, this scenario doesn’t exist since for a tibXML transaction to be initiated the INITOATOR.REQUEST message should arrive using the TIBCO Rendezvous transport.

Comparing Private Processes Messages Between tibXML and EZCommDifferences between private process messages in tibXML 3.6 and EZComm 5.3 are explained in the following sections:

• INITIATOR REQUEST

• INITIATOR RESPONSE

• RESPONDER.REQUEST

• RESPONDER.RESPONSE



INITIATOR REQUEST

Table 37 shows the INITIATOR.REQUEST fields that are different between tibXML3.6 and EZComm 5.3:

Table 37 INITIATOR.REQUEST Fields in tibXML 3.6 and EZComm 5.3

EZComm 5.3 Field tibXML 3.6 Field What are the differences?

fromTP hostName

toTP tpName In tibXML, toTP can be specified using either the tpName field or using a list of trading partners in the tpNameList.

When toTP is specified, tibXML sends the requests to all listed trading partners. Since EZComm doesn't support this feature, it takes the first partner name from this sequence and sends the request to that partner.

n/a tpNameList The list specifying trading partner names.

stringData

(plainRequest)

request In EZComm 5.3, a request can be sent on stringData (plainRequest), BinaryRequest, or an inputFile.

tibXML has only two types, request and requestFile, and EZComm 5.3 will check for the request data from these two types.

binaryRequest n/a

inputFile requestFile

n/a deleteRequestFile If specified in tibXML message, it will be ignored in EZComm 5.3.



INITIATOR RESPONSE

The message INITIATOR.RESPONSE will be published on the tibXML subject if the message INITIATOR.REQUEST is received on tibXML.

Table 38 shows the INITIATOR.RESPONSE fields that are different between tibXML3.6 and EZComm 5.3:

When the outbound File poller is used as the private process that invokes a tibXML transaction, the message INITIATOR.RESPONSE is published on the EZComm subject, such as AX.BC.Installation_Name.EZComm.INITIATOR.RESPONSE.

Table 38 INITIATOR.RESPONSE Fields in tibXML 3.6 and EZComm 5.3


fromTP hostName

toTP tpName Only the first trading partner from the tpNameList sequence will be selected.

In tibXML, toTP can be specified using either the tpName field or using a list of trading partners in the tpNameList. When toTP is specified, tibXML sends the requests to all listed trading partners. Since EZComm doesn't support this feature, it takes the first partner name from this sequence and sends the request to that partner.

n/a tpNameList The list specifying trading partner names.

stringData

(plainResponse)

response The field stringData (plainResponse) contains text data and binaryRespose contains binary data. If the field is received as a reference, the payload field will be populated in the responseFile field.

binaryResponse n/a

n/a deleteResponseFile

originalFileName n/a This field represents the actual file name of the file reference specified in the RESPONDER.REQUEST message



RESPONDER.REQUEST

Table 39 shows the RESPONDER.REQUEST fields that are different between tibXML3.6 and EZComm 5.3:

Table 39 RESPONDER.REQUEST Fields in tibXML 3.6 and EZComm 5.3


fromTP sourceTP (hostName)

EZComm 5.3 will always populate the fields hostname and tpName, while the field tpNameList will never be populated.

toTP destinationTP (tpName)

stringData

(plainRequest)

request EZComm 5.3 will populate the fields stringData (plainRequest), binaryRequest or requestFile field. The field requestFile will be populated if filename is received on the HTTP query string or if the request exceeds the large file threshold.

binaryRequest n/a

isBinaryFile n/a

inputFile requestFile

originalFileName n/a The field originalFileName will be populated as follows:

• Inbound File and FTP transports The actual filename at the time of polling from the source will be populated. The source is a directory in case of the File transport, and an FTP server in case of the FTP transport.

• HTTP If the URL/header carries the expression filename=<value>, it will be populated on originalFileName.

For the above scenario to work, on the outbound (Initiator) side the following must occur: the option Allow override Filename should be enabled for the partner and the INITIATOR.REQUEST message should have the field inputFile populated; the private process message should come from an outbound File Poller (OBFP).

• Inbound MIME message Any filename specified in the content disposition will be populated in the originalFileName field.



RESPONDER.RESPONSE

There are no significant differences between fields for tibXML 3.6 and for EZComm 5.3:

originalFileName

(cont.)n/a • Outbound MIME message Content disposition will

be populated with the originalFilename field in the following cases:

— INITIATOR.REQUEST payload comes in as file reference and signing, encryption, or attachments are specified;

— outbound File poller is used as private process;

— the content disposition populated with the filename comes from the INITIATOR.REQUEST private process message.

Table 39 RESPONDER.REQUEST Fields in tibXML 3.6 and EZComm 5.3


Table 40 RESPONDER.RESPONSE Fields in tibXML 3.6 and EZComm 5.3


stringData

(plainResponse)

response

binaryResponse n/a

content-type n/a

content-disposit

ionn/a



tibXML Public Messages

TIBCO BusinessConnect EZComm Protocol 5.3 is capable of sending or receiving messages either in the EZComm or tibXML format. The transport URL/subject is used to determine the public message format.

Inbound Processing Error in tibXMLWhen an EZComm operation is configured to publish the private process message in the tibXML format, BusinessConnect — while processing the incoming requests — publishes certain errors both on EZComm and tibXML subjects .

This happens when an error occurs and if any of the following in the incoming request can not be determined or is invalid:

• Transaction type

• operationID

• fromTp

• toTp

• business agreement between the partners

Outbound Public Messages in tibXMLThe following applies to outbound public messages in tibXML:

• The tibXML outbound public message are always MIME messages (except for passthrough) with multiple parts:

— The first MIME part always contains an XML that contains the header information (fromTP, toTP, transactionID, and so on).

— The second part of the MIME message contains the request.

• EZComm determines the outbound message packaging format based on the URL suffix of the primary outbound transport.

— HTTP If the URL contains /tibXML, the outbound message will be packaged in the tibXML format.


tibXML Public Messages | 117

— Email For this transport, the packaging format will be determined by the expression tibXML: in the subject.

— File or FTP For these transports tibXML packaging is not available. If a tibXML messages comes from the private process when one of these transports is used, this message will be sent out to EZComm.

• A message can be packaged in the tibXML format also when the URL doesn't contain the tibXML or EZComm suffix, provided that the checkbox Use tibXML packaging for the partner is selected.

This applies to situations when a partner is using a third-party system with the tibXML message format and when the URL doesn't contain tibXML.

Inbound Public Messages in tibXMLTIBCO BusinessConnect EZComm Protocol inspects the incoming URL suffix. If it contains tibXML, EZComm will try to extract the multi-part MIME message.

The first part of the MIME message will be the header XML and the partner information is extracted from this for unpacking the request.

tibXML Message FormattingThe tibXML public messages are formatted differently than the EZComm messages:

• The tibXML messages are always multi-part MIME messages, where the first part is always XML that contains the information about the transaction, such as operationID, from, to, and so on.

• The second body part for the tibXML messages is payload, while for the EZComm messages all transaction information is carried in URL/subject.

For more information on determining the public message format refer to MIME Message Packaging Options in tibXML.

During the migration of tibXML 3.x to EZComm 5.3, the URLs and subjects will be populated with the value tibXML and users don’t have to change these values after migration



tibXML Message PackagingSince the TIBCO BusinessConnect EZComm Protocol can package messages based on the URL/subject, users are responsible for making sure that the correct packaging format is specified in the URL.

For asynchronous transactions, users must make sure that the outgoing response is in the same format as the incoming request; for example, if the request arrives in the tibXML format, they must make sure that the outbound transport for response has tibXML in its URL/subject.

For the synchronous Request Response message, the outbound transport is not used for sending the response and users don’t have to take care of the transport URL/subject for the synchronous response.

The tibXML protocol supports the following public messaging options:

• MIME (Multipurpose Internet Mail Extensions) with optional S/MIME.

For more information, see MIME Message Packaging Options in tibXML.

• Pass-through mode — In this mode, the software does not package the data in any way. The software takes the original notify message that the private process sent and forwards it over the Internet to the trading partner.

For more information, see Passthrough Mode in tibXML.


MIME Message Packaging Options in tibXML | 119

MIME Message Packaging Options in tibXML

There are four MIME packaging options for the payload (content):

• Cleartext The payload is usually an XML string, but can be in any other format. In this case, where the payload is neither signed nor encrypted, the content should be a text string. The following combination of Content-Type and Content-Transfer-Encoding applies in this case:

— Content-Type=text/plain; Charset=UTF-8.

— Content-Type=text/xxx. Content-Transfer-Encoding is binary. The string is returned as is.

— Content-Type=text/xxx; Content-Transfer-Encoding=base64. The string is base64-decoded. A new string is formed from the resultant byte array and is returned.

— Content-Type=application/xxx;

Content-Transfer-Encoding=base64. The string is base64-decoded. The resultant byte array is returned.

• Ciphertext (encrypted) The payload is encrypted and packaged as an encrypted S/MIME object.

• Ciphertext (encrypted) and signed The payload is signed. The signed payload is then encrypted. Both parts are packaged as an encrypted S/MIME object.

• Signed The payload is signed and packaged as a signed S/MIME object.

The header is always an XML string that is packaged with the payload to form a two-part MIME object. Content-Type for the header should be set to text/plain; Charset=UTF-8, but this may be left blank.

When TIBCO BusinessConnect packages a private message as a public MIME message before sending it over the Internet, it packages only the contents of the ^data^ control tag from the aeRvMsg. TIBCO BusinessConnect strips the TIBCO Rendezvous subject name and message control block tags from the private aeRvMsg message before packaging the message for public transmission.



Passthrough Mode in tibXML

The passthrough mode is available with tibXML messages, only for HTTP and SMTP transports and only for the Notify operation. To send a message in the passthrough mode, select BusinessConnect>Operations Editor>EZComm>Notify_operation>Notify Request Action>tibXML Passthrough.

When the checkbox tibXML Passthrough is selected, the following will happen:

• TIBCO BusinessConnect will forward the outbound messages received from the private process without adding an envelope. No trading partner validation and no binding will occur.

• TIBCO BusinessConnect won’t be able to use audit tables. Audit logging requires mandatory fields, while in pass-through mode data is handled as a single block, with no discernible fields. However, duplicate detection based on the whole message is performed.

• Requests will be sent as a plain text and no MIME header, no signing, and no encryption will be available.

• If the File or FTP transports, the tibXML-passthrough option will be ignored.

In Outbound Passthrough Mode

• The Initiator modifies the outbound URL to contain tibXML-passthrough

• Available only when the outbound URL /subject contains tibXML-passthrough; available only for the tibXML partners, not for EZComm

• The outbound schema validation is available for the outbound passthrough messages

In Inbound Passthrough Mode

• Inbound messages are inspected for tibXML-passthrough

• The Responder identifies the incoming request as passthrough based on the value (tibXML-passthrough) supplied in the URL.

• Audit logs are performed with the partner name as <unknown> and the operation ID as BC/1.0/Notify

• The inbound schema validation is not available for the inbound passthrough messages.


Setting Timing Restrictions in tibXML | 121

Setting Timing Restrictions in tibXML

You can set timing restrictions in two places, as follows:

• Set default timing restrictions for an operation using the request and response panels in the Protocol Editor.

• Set customized timing restrictions for operations when used by a particular trading partner. For each trading partner, you specify the interfaces that a partner initiates and the interfaces that a partner responds to. You can accept the defaults or customize the settings for an operation. If you customize an operation’s settings for a particular trading partner, you override the default settings for the operation.

If you don’t enter a value into a field, and that field is considered for an operation, the defaults are used. If you override the default settings on any of these timing restrictions, be sure to coordinate with your partner so that you both use the same restrictions.

If you are changing the timing parameters in the Interfaces Initiated or Interfaces Responded to dialog, you override the settings that were made for each operation in the selected interface.



tibXML Migration

TIBCO BusinessConnect EZComm Protocol 5.3 is capable of understanding the tibXML private process messages, enabling the usage of your existing tibXML private processes to interact with an EZComm 5.3 system.

Still, it is recommend that you migrate your tibXML TIBCO ActiveMatrix BusinessWorks projects to EZComm TIBCO ActiveMatrix BusinessWorks projects, and to rely on the backward compatibility of EZComm 5.3 with tibXML private process messages only for situations where the tibXML private process is a custom Rendezvous program or an Integration Manager (IM) process.

Figure 20 shows the diagram for migrating projects between tibXML 3.6 and TIBCO BusinessConnect 5.3 running the EZComm protocol.

Figure 20 tibXML to EZComm Private Process Migration

The migration process contains several steps:

1. Migrating of TIBCO BusinessConnect 3.6 (tibXML ) data to TIBCO BusinessConnect 5.3 using TIBCO Administrator.

See TIBCO BusinessConnect Server Administrator’s Guide, Migrating From the Release 3.x to the Release 5.3.0.

BC 5.3

tibXML 3.6

BW project with

BC 5.3 palette

BW project with

tibXML 3.6

palette

Server Private Process

Legend

BC = TIBCO BusinessConnect

BW = TIBCO ActiveMatrix BusinessWorks

5

1 23 44

2a = Open BW project2b = Import migrated configuration data


tibXML Migration | 123

2. Migrating of the TIBCO ActiveMatrix BusinessWorks project, which contains two substeps:

a. The tibXML TIBCO ActiveMatrix BusinessWorks projects are automatically migrated when they are opened using TIBCO Designer 5.5 that contains the Business Connect 5.3 palette

b. Updating of the Business Connect connection resource with the configuration store values (specified in Step 1, cdata migration) and importing the configuration store data.

3. Sending messages from TIBCO BusinessConnect 5.3 (EZcomm) to tibXML 3.6

4. Sending messages from tibXML 3.6 to TIBCO BusinessConnect 5.3 (EZcomm)

5. Finishing migration of the TIBCO ActiveMatrix BusinessWorks project with the TIBCO BusinessConnect 5.3 palette.

The Recommended Migration Path

In order to properly migrate the old TIBCO ActiveMatrix BusinessWorks projects with the tibXML 3.6 palette into new TIBCO ActiveMatrix BusinessWorks project with the EZComm 5.3 palette, you need to perform the following step sequence: 1, 2a, 2b, and 5.

In this process, you will first open a tibXML 3.6 BusinessWorks project with the EZComm 5.3 BusinessWorks palette (2a) and then import the data from the BusinessConnect 5.3 configuration store (2b), concluding with the complete migration (5).

Once the migrated projects import the data from the EZComm 5.3 configuration store, such as after importing EZComm 5.3 schemas, these processes will no longer be able to communicate with the tibXML processes. From this point on, the migrated projects will send messages on the EZComm subject.

The Migration Path that Does Not Import the Configu ration Data

If you only perform the sub-step 2a but not the sub-step 2b, which means that the data from the BusinessConnect 5.3 configuration store is not imported, the migrated projects will still be able to communicate with the tibXML 3.x systems; for example, the messages continue to be sent on tibXML subjects.

This incomplete migration path is not recommended for the following reasons:

• The private process message schema in the TIBCO BusinessConnect 3.6 palette does not match the one in TIBCO BusinessConnect 3.6. As a result, the TIBCO BusinessConnect 3.6 palette is not able to receive some of the messages generated by TIBCO BusinessConnect 3.6.



• Since EZComm 5.3 generates the private process messages the same way as TIBCO BusinessConnect 3.6, they will not be received by the TIBCO BusinessConnect 3.6 palette, or by the TIBCO BusinessConnect 3.6 palette opened using the TIBCO BusinessConnect 5.3 palette (such as the TIBCO BusinessConnect 3.6 project opened in TIBCO Designer 5.5 that has the TIBCO BusinessConnect 5.3 palette).

The two activities that are affected are:

• Receive Request Activit y There are no requestFile or deleteRequestFile elements defined in the TIBCO BusinessConnect 3.6 palette schema: if the Responder Request message contains such fields, the TIBCO BusinessConnect 3.6 palette (TIBCO BusinessConnect 3.6 palette migrated before the import) will fail.

• Receive Response Activity There are no responseFile or deleteResponseFile elements defined in migrated 3.6 palette schema: if an Initiator Response message has such fields, the TIBCO BusinessConnect 3.6 palette will fail.


| 125

Chapter 12 EZComm 5.1 to 5.3 Migration

This appendix explains migration of TIBCO BusinessConnect EZComm Protocol from version 5.1 to version 5.3.

Topics


• Public Messages Migration, page 127

• Private Process Migration, page 128

• Outbound File Poller Migration, page 130


126 | Chapter 12 EZComm 5.1 to 5.3 Migration

Overview

Configuration changes in TIBCO BusinessConnect EZComm Protocol 5.3 are as follows:

• Operations have been changed to contain three instead of two levels. All operations migrated from the version 5.1 will have Empty in the middle level; for example, BC/Notify will be migrated to BC/Empty/Notify.

• XML schema validation is split into inbound and outbound schema validations, which are available in the Operations tab.

• Signing and encryption options are moved to the Request Action Tab.

TIBCO BusinessConnect EZComm Protocol 5.3.0 is backward compatible with TIBCO BusinessConnect EZComm Protocol 5.1.0.

Important migration points are explained in the following sections:

• Public Messages Migration

• Private Process Migration

• Outbound File Poller Migration

Operation changes between tibXML and EZComm are explained in the TIBCO BusinessConnect Release Notes, section Changes in Functionality.


Public Messages Migration | 127

Public Messages Migration

The Notify operation from TIBCO BusinessConnect 5.1 is defined in two levels as <category>/<operation>, while the same operation in TIBCO BusinessConnect 5.3 is defined in three levels as <category>/<version>/<operation>.

The migrated Notify operation from TIBCO BusinessConnect 5.1 is denoted with an 'Empty' version identifier, which is done when operations or the TIBCO BusinessConnect 5.1 configuration store are migrated to version 5.3.

TIBCO BusinessConnect EZComm 5.3 as Initiator and 5 .1. as Responder

When sending the request to the trading partner, for Notify operation TIBCO BusinessConnect 5.3 verifies the version number of the operation. If this value is 'Empty', then it generates a two-level operation(<Category>/<Operation>) and sends the request to the trading partner.

TIBCO BusinessConnect EZComm 5.3 as Responder and 5 .1 as Initiator

When using EZComm 5.3 as the Responder, it will receive a two level operation (such as BC/Notify). It will then interpret it as three level operation with Empty as the middle level (such as BC/Empty/Notify).



Private Process Migration

TIBCO BusinessConnect EZComm Protocol version 5.1 private processes can continue to send messages to version 5.3 without any changes.

EZComm 5.1 Private processes should be able to interpret the version 5.3 private process messages without any changes.

BusinessWorks Palette Migration

A migration diagram for private processes is presented in Figure 21.

Figure 21 EZComm 5.1 to EZComm 5.3 Private Process Migration

The migration process contains these steps:

1. Migrate the Configuration Store

Export the 5.1 configuration store and import it into BusinessConnect 5.3 system. See TIBCO BusinessConnect Trading Partner Administration Guide, Export Schemas.

2. Migrate the BusinessConnect Palette

Migrate EZComm 5.1 projects into EZComm 5.3 projects by opening them with TIBCO Designer that contains the Business Connect 5.3 palette. Once opened, these projects can no longer communicate with the BusinessConnect 5.1 system. The OperationID field will contain a version number as empty , but the message format will still be as in EZComm 5.1.

BC 5.3

BC 5.1

BW project with

BC 5.3 palette

BW project with

BC 5.1 palette

Server Private Process

Legend

BC = TIBCO BusinessConnect

BW = TIBCO ActiveMatrix BusinessWorks

3

1 2


Private Process Migration | 129

3. Complete Migration

To complete the migration, the configuration store must be imported into the BusinessWorks project.

After the migration, the EZComm 5.3 schema will be available in the BusinessWorks activities, and messages will be published in the EZComm 5.3 format.



Outbound File Poller Migration

The directory structure for the EZComm 5.1 can be one of the following:

• EZComm\Partner, or

• EZComm\Partner\Category_Operation.

Depending on their placement in these folders, the files will be published as follows:

• If files are placed in the folder EZComm\Partner, they will be published on the version 5.3 default operation (BC\1.0\Notify)

• If files are placed in the folder EZComm\Partner\Category_Operation, they will be published on operation Category/Empty/Operation.


| 131

Chapter 13 Troubleshooting

This appendix offers troubleshooting advice for the EZComm protocol.

Topics

• Troubleshooting EZComm, page 132


132 | Chapter 13 Troubleshooting

Troubleshooting EZComm

ORIG_FILE_NAME and ORIG_FILE_PATH are not populated when using outbound File poller to send files from private processes

When using outbound File poller to send files from private processes, the file slots ORIG_FILE_NAME and ORIG_FILE_PATH may not be populated.

The ORIG_FILE_NAME and ORIG_FILE_PATH properties are populated by the protocol to indicate the original source of data, if any. When you use outbound File poller in EZComm, these properties are not set but the location of the source file is set on the OUTPUT_SOURCE_DIR and SRC_FILE_NAME properties instead.

Outbound transactions for HTTP in EZComm are not en tered in the non-repudiation log

Non-repudiation logs, in general, are used for signed messages to avoid disputes between trading partners. When using HTTP with EZComm, there are two types of signed messages that can be exchanged:

• Inbound signed messages These messages are posted to the non-repudiation log. Since the trading partner already signed such message and the signature can be verified, there can be no dispute that the message came from this specific trading partner.

• Outbound signed messages When a signed message is sent using HTTP outbound, there is no ability to request a receipt. The trading partner’s HTTP server can officially acknowledge that the message was received, but it cannot verify the signature on the message. The acknowledgement from the HTTP server about the message arrival is not the same as the acknowledgement from the trading partner who actually received and processed the message.

Therefore, if TIBCO BusinessConnect would post such outbound signed message into the non-repudiation log, the other trading partner could still dispute that they received the message. For that reason, HTTP transport in EZComm does not enter outbound signed messages in the non-repudiation log.

When I import the whole configuration in EZComm, th e operation is not imported

When an operation in a .csx file already exists in the BusinessConnect 5.3 system, upon importing the .csx file this operation will not be imported.


Troubleshooting EZComm | 133

For example, if you try to import the operation BC/version/operation, which exists by default, you need to rename the existing BC/version/operation (such as BC/5.3/operation1) in order to import a new operation with the same name. The exception is the default operation BC/1.0/Notify, which cannot be renamed or deleted: this operation has to be updated manually.


134 | Chapter 13 Troubleshooting


| 135

Appendix A FTP Script Examples

This appendix contains some sample scripts for EZComm.

Topics


• First Tutorial Example, page 137

• Second Tutorial Example, page 141

• Third Tutorial Example, page 143


136 | Appendix A FTP Script Examples

Overview

The following script examples are included with TIBCO BusinessConnect:

• First Tutorial Example shows simple FTP file transfers using the FTP API provided with TIBCO BusinessConnect.

• Second Tutorial Example shows how to call Java methods from inside the FTP scripts and how to execute a batch/shell program before sending the file to the FTP server.

• Third Tutorial Example shows how to connect the SSHFTPClient object to the SSHFTP server.


First Tutorial Example | 137

First Tutorial Example

The putexample.txt script puts the document to the FTP server. The mgetexample.txt script does an mget from the FTP server of all files that match a particular search filter, which in this example is the trading host name.

How putexample.txt Works

This script gets the FTPClient object from the job variable that is created at runtime by BusinessConnect. The FTPClient object is used to connect to the FTP server. This works only in non-proxy mode. It checks to see if the examples/BC directory is available. If it is, it puts the file created by the Initiator's outbound process. If the examples/BC directory is not present, that directory is created before the file is actually stored in the FTP server.

If there are connection failures, a flag called retryScripts is set to true and passed on to TIBCO BusinessConnect to retry the execution when retry of the outbound process occurs.

How mgetexample.txt Works

This script gets the FTPClient object from the job variable that is created at runtime by TIBCO BusinessConnect. FTPClient object is used to connect to the FTP server. It checks to see if the examples/BC directory is available. If it is, the script calls executeMgetCmd to get all the files from the FTP Server.

Once the files are successfully retrieved, the examples/BC directory is deleted. If the files could not be retrieved for some reason, for example, if a put is happening at the same time and the file descriptor is being locked by another process, then the examples/BC directory is not removed.

Tutorial Files

The following files are part of this tutorial:

• BC_installation_directory\samples\bc\ftpscripts\putexample.txt

• BC_installation_directory\samples\bc\ftpscripts\mgetexample.txt

These are both EcmaScript files.

How to Send Files

Send a document using BusinessWorks process as described in Chapter 10, File Pollers.



Set Up the First Tutorial

Steps to Perform on the Initiator Machine

The following steps must be performed for the Initiator machine:

1. Configure trading partners and a business agreement as described in Import the Tutorial.

2. For the participant Seller, click the Transports tab for the EZComm protocol.

3. Click Add.

4. Enter a name for the transport in the Transport Name field.

5. Select FTP in the Transport Type dropdown list.

6. Click OK.

7. Enter other information as needed. See TIBCO BusinessConnect Trading Partner Administration Guide, FTP/S Outbound if you need help.

8. Select Script in the File Processing dropdown list.

9. Click change in the Scripts field.

10. Select Uploaded File from the Type dropdown list.

11. Click Browse.

12. Select BC_installation_directory\samples\bc\ftpscripts\putexample.txt.

13. Click Open.

14. Click OK.

15. Click Save.

16. Click TIBCO BusinessConnect > BusinessAgreements > Buyer-Seller.

17. Click the EZComm protocol binding.


19. Select FTP as the Primary Transport in the Outbound Transports for Host ’Buyer’ area.


Steps to Perform on the Responder Machine

The following steps must be performed for the Responder machine:

1. Configure trading partners and a business agreement as described in Configuring the Responder TIBCO BusinessConnect.


First Tutorial Example | 139

2. Click TIBCO BusinessConnect > BusinessAgreements > Buyer-Seller.



5. Click Edit FTP Settings in the Inbound Transports for Partner ’Buyer’ area.

6. Configure FTP. If you need help, see TIBCO BusinessConnect Trading Partner Administration Guide, Select and Configure FTP/S Inbound.




10. Click Browse.

11. Select BC_installation_directory\samples\bc\ftpscripts\mgetexample.txt.

12. Click Open.

13. Click OK.

14. Select the Delete File checkbox.


Run the First Tutorial ExampleTo run the first tutorial example, do the following:

1. Start TIBCO BusinessConnect on the Initiator and Responder machines.

2. Send a document using the outbound File poller.

To configure TIBCO BusinessConnect to poll a directory, do the following:

a. Create a directory in which you will put the document that will be transmitted using the FTP script. This directory needs to be named according to the conventions explained in TIBCO BusinessConnect Trading Partner Administration Guide, field Directory to Monitor in Table 43, Outbound File Poller Fields.

b. Specify Seller for the TpName directory. If your base directory is BaseDir, the directory path should be BaseDir/Seller.

c. In TIBCO Administrator, click the Application Management > BusinessConnect > Configuration link in the left panel.

d. Click the BusinessConnect link in the right panel.

e. Click the Private Process Configuration tab.



f. Click the EZComm link in the Outbound File Poller Configuration area.

g. Select the Enable checkbox.

h. In the Directory to Monitor field, type BaseDir/Seller/*.*.

i. Click Save twice.

j. Click Deploy.

k. Click OK.

l. Restart the BusinessConnect server if it was not started when you clicked Deploy.

3. Copy the file BC_home\samples\EZComm\sampleXML\xsd\101.xml into BaseDir/Seller.

Expected ResultsAfter the Initiator BusinessConnect receives the file from the TIBCO ActiveMatrix BusinessWorks process or picks up the file from the outbound file poller directory, the following will happen:

• BusinessConnect establishes contact with the FTP server, passing the user name and password specified in the FTP transport configuration for Seller.

• BusinessConnect then invokes the putexample.txt script. The script looks for the directory examples/BC in the FTP root directory and creates them if they do not exist.

• Finally, the file is written to examples/BC.

On the Responder, BusinessConnect polls the directory specified in the inbound FTP configuration in the business agreement. When a file is detected, BusinessConnect runs the mgetexample.txt script, which looks for all the files in the examples/BC directory.


Second Tutorial Example | 141

Second Tutorial Example

The modifyexample.txt script shows how to call Java methods from inside the FTP scripts and how to execute a batch/shell program before sending the file to the FTP server. The batch/shell program calls a Java program that modifies the document by adding CRLF (\r\n) at the end of the document. The executePutCmd method is then executed to store the file at the FTP server.

This example is a demonstration that Java classes can be called from scripts at runtime and external programs can be called by using the Java runtime class.

How modifyexample.txt Works

This script is the same as putexample.txt except for one minor change. Before connecting to the FTP server, the source file name, which is a reference to the file that is stored locally before the script execution takes place, is sent to the executeProgram method in the RunProgram class. This method sends the fileName reference to a batch/shell program BC_installation_directory\samples\bc\ftpscripts\bcfilemodifier. The batch file/shell program calls the Java class ModifyFile, which adds a CRLF at the end of the document file that is being transferred to the FTP server. Once the file is modified it is stored on the FTP server that is available to the trading partner.

If you want to perform a full round trip of your transaction, you can upload mgetexample.txt from the first example to retrieve the files from the FTP server so that the Responder trading partner can process the document that was uploaded after the modification.

Tutorial Files


• BC_installation_directory\samples\bc\ftpscripts\modifyexample.txt

• BC_installation_directory\samples\bc\ftpscripts\ftpexample.jar

Set Up the Second TutorialThe following steps are necessary to set up this tutorial:

1. Configure the participants and business agreement on the Initiator following the procedure described in Set Up the First Tutorial.

2. Stop the BusinessConnect server.

3. Copy ftpexample.jar to BC_installation_directory/hotfix/lib.



4. Add these two properties in the .tra file in the directory TIBCO_HOME/tra/domain/domain/application/BusinessConnect directory. There is a .tra file for every BusinessConnect engine.

— java.property.bc.user.execProgramName: bcfilemodifier

— java.property.bc.user.execProgramDir: BC_installation_directory\samples\bc\ftpscripts

Run the Second Tutorial ExampleTo run modifyexample, do the following:

1. Start the BusinessConnect server.

2. Send a document using one of the mechanisms described in Run the First Tutorial Example.

Expected ResultsYou will notice that the file that is transferred to the FTP server location will contain the extra CRLF. If you are trying to process this document on the Responder, there will be extra CRLF at the end of the file.


Third Tutorial Example | 143

Third Tutorial Example

Two scripts are used for the third tutorial example:

• The ssh_putexample.txt script, which puts the document to the SSHFTP server

• The ssh_mgetexample.txt script, which retrieves multiple files from the SSHFTP server. These files match a particular search filter, which in this example is the extension of the filename as well as the size of the file.

How ssh_putexample.txt Works

The ssh_putexample.txt script gets the SSHFTPClient object from the job variable that is created at runtime by BusinessConnect.

The SSHFTPClient object is used to connect to the SSHFTP server, both in proxy or non-proxy mode. It checks whether the examples1 directory is available and proceeds as follows:

• If the examples1 directory is present, the script puts in the file created by the Initiator's outbound process.

• If the examples1 directory is not present, it is created before the file is actually stored on the SSHFTP server.

If there are connection failures, a flag called retryScripts (with the constant name defined in the API com.tibco.ax.fw.runtime.transport.sshftp.SSHFTPClient.RETRY_SLOT) may be used to set the value as true, and passed on to BusinessConnect to retry the execution when retry of the outbound process occurs.

How ssh_mgetexample.txt Works

The ssh_mgetexample.txt script gets the SSHFTPClient object from the job variable that is created at runtime by BusinessConnect.

The SSHFTPClient object is used to connect to the SSHFTP server. It checks whether the examples1 directory is available. If it is, the script calls executeMgetCmd to get all the files from the SSHFTP Server.

Once the files are successfully retrieved, the files from the examples1 directory are deleted. If the files could not be retrieved for some reason (such as when a communication failure happens), the corresponding tracing and auditing entries are created. In such case, the script retrieves all files from the examples2 directory whose extension is *.bin and whose size is greater than or equal to 200 KB. Upon successful retrieval, the retrieved files are deleted.



Tutorial Files


bc_home\examples\bc\sshftpscripts\ssh_putexample.txt

bc_home\examples\bc\sshftpscripts\ssh_mgetexample.txt

These are both EcmaScript files.

How to Send Files

For this example, send a document using BusinessWorks process as described in Chapter 10, File Pollers.

Set Up the Third Tutorial

Steps to Perform on the Initiator Machine

The following steps must be performed on the Initiator machine:

1. Configure trading partners and a business agreement as described in Configuring the Initiator TIBCO BusinessConnect.

2. For the participant Seller, click the Transports tab for the EZComm protocol.

3. Click Add.

4. Enter the transport name in the Transport Name field.

5. Select SSHFTP in the Transport Type dropdown list.

6. Click OK.

7. Enter other information as needed.

See the TIBCO BusinessConnect Trading Partner Administration Guide, Configure SSHFTP Outbound for more information.




11. Click Browse.

12. Select bc_home\examples\bc\sshftpscripts\ssh_putexample.txt.

13. Click Open.

14. Click OK.

15. Click Save.



16. Click BusinessConnect > BusinessAgreements > Buyer-Seller.



19. Select SSHFTP as the Primary Transport in the Outbound Transports for the Host 'Buyer' area.


Steps to Perform on the Responder Machine

The following steps must be performed for the Responder machine:

1. Configure trading partners and a business agreement as described in Configuring the Responder TIBCO BusinessConnect.

2. Click BusinessConnect > BusinessAgreements > Buyer-Seller.



5. Click Edit SSHFTP Settings in the Inbound Transports for Partner'Buyer' area.

6. Configure FTP.

For more information, see the TIBCO BusinessConnect Trading Partner Administration Guide, Select and Configure SSHFTP Inbound.




10. Click Browse.

11. Select bc_home\examples\bc\sshftpscripts\ssh_mgetexample.txt.

12. Click Open.

13. Click OK.

14. Select the Delete File checkbox.




Run the Third Tutorial Example To run the third tutorial example, do the following:

1. Start BusinessConnect on the Initiator and Responder machines.

2. Send a document using the outbound File poller.

To configure BusinessConnect to poll a directory, do the following:

a. Create a directory in which you will put the document that will be transmitted using the FTP script. This directory must be named according to the conventions explained in the TIBCO BusinessConnect Trading Partner Administration Guide, in the field Directory to Monitor in Table 43, Outbound File Poller Fields.

b. Specify Seller for the TpName directory. If your base directory is BaseDir, the directory path should be BaseDir/Seller.

c. In TIBCO Administrator, click the Application Management > BusinessConnect > Configuration link in the left panel.

d. Click the BusinessConnect link in the right panel.

e. Click the Private Process Configuration tab.

f. Click the EZComm link in the Outbound File Poller Configuration area.

g. Select the Enable checkbox.

h. In the Directory to Monitor field, type BaseDir/Seller/*.*.

i. Click Save twice.

j. Click Deploy.

k. Click OK.

l. Restart the BusinessConnect server if it was not started when you clicked Deploy.

3. Copy the file bc_home\samples\EZComm\sampleXML\xsd\101.xml into the directory BaseDir/Seller.



Expected Results After the Initiator BusinessConnect receives the file from the BusinessWorks process, or picks up the file from the outbound File poller directory, the following will happen:

• BusinessConnect will establish contact with the SSHFTP server and authenticate with the selected authentication method specified in the SSHFTP transport configuration for Seller (either rsa/dsa public key or user name/password).

• BusinessConnect then invokes the ssh_putexample.txt script. The script looks for the directory examples1 in the SSHFTP root directory, and creates it if it does not exist.

• Finally, the file is written to the directory examples1.

On the Responder machine, BusinessConnect runs the configured script that polls the specified directories.

When a file is detected, BusinessConnect retrieves this file through the script ssh_mgetexample.txt. This script looks for files in the examples1 and examples2 directories as described above.


Index | 149

Index

A

about EZComm 2

about EZComm public messages 40

about schema validation in EZComm 40

add binding for the host 66

add new category 47

add new operation 48

add new version 48

add properties 54

Asynchronous Request Response operation 45

audit logs for EZComm 90

C

caching of schemas 40

configure agreement protocol binding for

EZComm 65

customer support xvii

D

delete properties 54

Document Security for Business Agreements 71

duplicate message detection 4, 41

E

edit agreement for Initiator

Show Advanced 73

error codes 121

exchanging URIs

Email transport 34

File transport 34

FTP transport 35

HTTP transport 36

EZComm

error messages 86

features 3

general messages 86

Initiator Inbound Response 79

Initiator messages 77

Initiator Outbound Request 77

logging support 4

operation support 4

Responder Acknowledgement 85

Responder Inbound Request 81

Responder messages 81

Responder Outbound Response 83

security 4

support for multiple attachments 4

support for private transports 3

support for public transports 3

tibXML protocol integration 4

XML validation 4

EZComm public messages overview 40

EZComm URIs exchange 34

ezcomm.notify.email.preserveSubject 54

F

File transport 103

fileName 36

first tutorial example 137


150 | Index

H

Host can Initiate

Override Outbound Settings 67

I

inbound duplicate detection criteria 42

M

managing properties 54

mgetexample.txt example 137

migration overview 126

modifyexample.txt example 141

N

non-repudiation logs for EZComm 93

Notify operation 43

O

Operation tab 49

outbound duplicate detection criteria 41

outbound File Poller migration 130

outbound File Pollers for EZComm 102

P

Partner Can Initiate

Override Inbound Settings 69

private process migration 128

public messages migration 127

putexample.txt example 137

R

Request Action tab 50

resend logs for EZComm 96

resending EZComm private process messages 88

Response Action tab 51

run the first tutorial example 139

run the third tutorial example 146

running the tutorial 26

S

second tutorial example 141

set up the first tutorial 138

set up the property ezcomm.interior.pp.threshold 57

set up the property

ezcomm.notify.email.preserveSubject 54

set up the second tutorial 141

set up the third tutorial 144

shadow credential usage for EZComm 71

statuscode and statusmsg field reference 121

support, contacting xvii

Synchronous Request Response operation 44

T

technical support xvii

third tutorial example 143

expected results 147

how to send files 144

ssh_mgetexample.txt 143

ssh_putexample.txt 143

steps on the Initiator machine 144

steps on the Responder machine 145

tutorial files 144

TIBCO_HOME xiv


Index | 151

tibXML

deprecated features 125

packaging 108

passthrough 108

private process integration 109

protocol Integration 105

tibXML message formatting 117

tibXML message packaging 118

tibXML private process migration 122

Transports for Business Agreements 72

troubleshooting EZComm 132

troubleshooting the tutorial 39

tutorial

about 8

assign components to machines 11

configure connections to Initiator

BusinessConnect 23

configure connections to Responder

BusinessConnect 25

configure Initiator business agreement 16

configure Responder business agreement 20

configure Responder default host 18

configure Responder partner 19

configure the Initiator default host 13

configure the Initiator partner 14

configuring Initiator BusinessConnect 13

configuring Responder BusinessConnect 18

configuring the private processes 22

create deployment configuration 9

deploy and start BusinessConnect 11

edit application configuration 10

import operation 12

open the BusinessWorks project 22

operation bindings for Initiator business

agreement 16

operation bindings for Responder business

agreement 20

override transport for Initiator business

agreement 17

override transport for Responder business

agreement 21

set up server transport 10

U

using shadow credentials to receive signed or

encrypted messages 71

using shadow credentials to send signed or encrypted

messages 71

tib bc ezcomm users guide

Documents