tibco businessconnect ebxml protocol user s guide · pdf filetibco businessconnect ebxml...

TIBCO BusinessConnect™ ebXML

Protocol

User’s Guide — ebMS3/AS4 Standard

Software Release 6.0May 2013

Two-Second Advantage®

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 THE LICENSE FILE) 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.

TIBCO, Two-Second Advantage, TIBCO BusinessConnect, TIBCO Administrator, TIBCO ActiveMatrix BusinessWorks, TIBCO Runtime Agent, TIBCO Designer, TIBCO Rendezvous, TIBCO Enterprise Message Service, and TIBCO Hawk are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries.

Enterprise Java Beans (EJB), Java Platform Enterprise Edition (Java EE), Java 2 Platform Enterprise Edition (J2EE), and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle Corporation 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 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 © 2000-2013 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information

TIBCO BusinessConnect ebXML Protocol User’s Guide — ebMS3/AS4 Standard

| iii

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

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

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

TIBCO BusinessConnect ebXML Protocol Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Other TIBCO Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Third-party Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii

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

Connecting with TIBCO Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

How to Join TIBCOmmunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

How to Access TIBCO Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

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

Chapter 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

TIBCO BusinessConnect ebXML Protocol Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2 Process Flows and Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Public and Private Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Private Messages and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Public Messages and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Processing ebMS3 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

One-Way Push Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

One-Way Pull Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Asynchronous Two-Way Push-and-Push Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Processing Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Message Partition Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Reception Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Receipt Reply Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Duplicate Elimination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Security Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23


iv | Contents

Digital Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

UsernameToken for Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

PullRequest Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Transport Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Error Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 3 Preparing to Use TIBCO BusinessConnect ebXML Protocol . . . . . . . . . . . . . . . . . . 29

Exchanging Information with Your Trading Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Configuring Your BusinessConnect Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Transports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

External Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 4 Managing ebMS3 Operation Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Managing ebMS3 Operation Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Adding Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Transaction Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Exporting Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Importing Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 5 Setting Up Trading Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Configuring ebMS3/AS4 Standard for Trading Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Adding Domain Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

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

Configuring ebMS3/AS4 Standard for Trading Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

General Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Transports Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Chapter 7 Configuring Agreement Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Configuring Business Agreements with ebMS3 Protocol ebMS3/AS4 Standard . . . . . . . . . . . . . . . . . . . . . . . . . 62

Configuring Operation Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Binding Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Editing Operation Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Operation Settings Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Action Settings Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Transports Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Setting Document Security Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66


Contents | v

Configuring Transports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Outbound Transports for Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Allowed Inbound Transports for Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Overriding Outbound Transport Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Overriding Participant Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Chapter 8 Private Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

Configuring Private Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Standalone Private Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

TIBCO ActiveMatrix BusinessWorks Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Private Process Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Outbound Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Request Acknowledgment Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Inbound Response Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Inbound Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Outbound Response Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Response Acknowledgment Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Advisory Signal Message Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Error Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Additional Data Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Configuring Private Processes with TIBCO ActiveMatrix BusinessWorks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Configuring BCServerConfig Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Configuring Send and Receive Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Chapter 9 Viewing Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

Logging Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Viewing Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Transaction Details View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

State Details View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Non-Repudiation Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Resendable Transactions Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Transaction States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Resend History Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Chapter 10 Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Setting Up the Sample. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


vi | Contents

Setting Up the Sample in TIBCO Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Setting Up the Sample in TIBCO ActiveMatrix BusinessWorks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Running the Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

One-Way Push Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

One-Way Pull Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Appendix A Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Appendix B Property Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Appendix C Smart Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Appendix D Public Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

ebMS3 Public Message Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

SOAP Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

UserMessage Element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

SignalMessage Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169


Figures | vii

Figures

Figure 1 ebMS3 Components in TIBCO BusinessConnect ebXML Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 2 Processing One-Way Push Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 3 Processing One-Way Pull Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 4 Processing Asynchronous Two-Way Push-and-Push Transactions . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 5 MPC for One-Way Pull Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 6 Message Delivery with MSH Receipt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 7 Receipt Reply Pattern: callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 8 Receipt Reply Pattern: response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 9 TIBCO ActiveMatrix BusinessWorks Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Figure 10 ebMS3 User Message Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Figure 11 ebMS3 Signal Message Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161


viii | Figures


Tables | ix

Tables

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

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

Table 3 One-Way Operation Type: One-Way Transaction Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Table 4 One-Way Operation Type: Request Action Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Table 5 Pull Operation Type: Pull Transaction Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Table 6 Pull Operation Type: Pull Request Action Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Table 7 Pull Operation Type: Pull Response Action Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Table 8 Two-Way Operation Type: Two-Way Transaction Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Table 9 Two-Way Operation Type: Request/Response Action Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Table 10 Trading Host General Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Table 11 Trading Partner General Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Table 12 Document Security Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Table 13 Outbound Transports for Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Table 14 Inbound Transport Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Table 15 ae/ebMS3/InitiatorRequest Message Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Table 16 ae/ebMS3/InitiatorAck Message Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Table 17 ae/ebMS3/InitiatorResponse Message Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Table 18 ae/ebMS3/ResponderRequest Message Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Table 19 ae/ebMS3/ResponderResponse Message Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table 20 ae/ebMS3/ResponderAck Message Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table 21 ae/ebMS3/Advisory Signal Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Table 22 ae/ebMS3/Advisory Error Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Table 23 ae/BC/Attachment Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Table 24 ae/BC/TradingPartner Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Table 25 Audit Log, Summary View Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Table 26 Audit Log, Transaction Details View Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Table 27 Non-Repudiation Log Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Table 28 Resendable Transactions Log Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108


x | Tables

Table 29 Transaction States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Table 30 Resend History Log Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Table 31 Participant Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Table 32 Status Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Table 33 Property Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Table 34 Smart Routing Fields for ebMS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Table 35 UserMessage Element in ebMS3 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Table 36 Signal Message Element in ebMS3 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166


| xi

Preface

TIBCO BusinessConnect ebXML Protocol is a plug-in to TIBCO BusinessConnect, enabling users of TIBCO BusinessConnect to conduct e-commerce with ebXML protocol.

Topics

• Related Documentation, page xii

• Typographical Conventions, page xiv

• Connecting with TIBCO Resources, page xvii


xii | Related Documentation

Related Documentation

This section lists documentation resources you may find useful.

TIBCO BusinessConnect ebXML Protocol Documentation

The following documents form the TIBCO BusinessConnect ebXML Protocol documentation set:

• TIBCO BusinessConnect ebXML Protocol Installation and Configuration Read this manual for instructions on site preparation and installation.

• TIBCO BusinessConnect ebXML Protocol User’s Guide — ebMS2 Standard Read this manual to learn how to use the software to process ebXML transactions based on the ebMS2 standard. This manual also contains a tutorial to help you get started with TIBCO BusinessConnect ebXML Protocol.

• TIBCO BusinessConnect ebXML Protocol User’s Guide — ebMS3/AS4 Standard Read this manual to learn how to use the software to process ebXML transactions based on the ebMS3/AS4 standard. This manual also contains a tutorial to help you get started with TIBCO BusinessConnect ebXML Protocol.

• TIBCO BusinessConnect ebXML Protocol Release Notes Read the release notes for a list of new and changed features. This document also contains lists of known issues and closed issues for this release.

Other TIBCO Product Documentation

You may find it useful to read the documentation for the following TIBCO products:

• TIBCO BusinessConnect™

• TIBCO ActiveMatrix BusinessWorks™

• TIBCO Administrator™

• TIBCO Rendezvous®

• TIBCO Designer™

• TIBCO Hawk®

• TIBCO Enterprise Message Service™

• TIBCO Runtime Agent™


Preface | xiii

Third-party Documentation

You may find it useful to read the following third-party documentation:

• [ebMS3CORE] OASIS ebXML Messaging Services Version 3.0: Part1, Core Features, 1 October 2007, OASIS Standard

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.pdf

• [AS4] AS4 Profile of ebMS 3.0 Version 1.0, January 2013, OASIS Standard

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/os/AS4-profile-v1.0-os.pdf

• [SOAP12] M. Gudgin, et al, SOAP Version 1.2 Part 1: Messaging Framework, 2003

http://www.w3.org/TR/soap12-part1/

• [SOAPATTACH] J. Barton, et al, SOAP Messages with Attachments, 2000

http://www.w3.org/TR/SOAP-attachments

• [WSS11] Web Services Security: SOAP Message Security 1.1. OASIS Standard incorporating Approved Errata. 1 November 2006

http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf

• [WSS11-UT] Web Services Security UsernameToken Profile 1.1. OASIS Standard. 1 February 2006

http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf

• [XMLDSIG] Donald Eastlake, et al, eds, XML-Signature Syntax and Processing, 2002

http://www.w3.org/TR/xmldsig-core/

• [XMLENC] D. Eastlake, et al, XML Encryption Syntax and Processing, 2002.

http://www.w3.org/TR/xmlenc-core/

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.pdf

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/os/AS4-profile-v1.0-os.pdf

http://www.w3.org/TR/soap12-part1/

http://www.w3.org/TR/SOAP-attachments

http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf

http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf

http://www.w3.org/TR/xmldsig-core/

http://www.w3.org/TR/xmlenc-core/


xiv | Typographical Conventions

Typographical Conventions

The following typographical conventions are used in this manual.

Table 1 General Typographical Conventions

Convention Use

ENV_NAME

TIBCO_HOME

TIBCO products are installed into an installation environment. A product installed into an installation environment does not access components in other installation environments. Incompatible products and multiple instances of the same product must be installed into different installation environments.

An installation environment consists of the following properties:

• Name Identifies the installation environment. This name is referenced in documentation as ENV_NAME. On Microsoft Windows, the name is appended to the name of Windows services created by the installer and is a component of the path to the product shortcut in the Windows Start > All Programs menu.

• Path The folder into which the product is installed. This folder is referenced in documentation as TIBCO_HOME.

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]


Preface | xv

italic font Italic font is used in the following ways:

• To indicate a document title. For example: See TIBCO BusinessConnect 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

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 (Cont’d)

Convention Use


Preface | xvii

Connecting with TIBCO Resources

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts. It is a place to share and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs, and access to a variety of resources. To register, go to http://www.tibcommunity.com.

How to Access TIBCO Documentation

You can access TIBCO documentation here:

http://docs.tibco.com

How to Contact TIBCO Support

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

• For an overview of TIBCO Support, and information about getting started with TIBCO 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.

http://www.tibcommunity.com

http://docs.tibco.com

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

https://support.tibco.com


xviii | Connecting with TIBCO Resources


Introduction | 1

Chapter 1 Introduction

This chapter gives an overview of TIBCO BusinessConnect ebXML Protocol and lists the product features.

Topics

• Overview, page 2

• TIBCO BusinessConnect ebXML Protocol Architecture, page 3

• Features, page 5

This documents focuses on the ebMS3/AS4 standard of the protocol.


2 | Chapter 1 Introduction

Overview

ebXML (electronic business XML) is a business protocol that allows buyers, sellers, and intermediaries to securely share XML or non-XML business documents and messages reliably over the Internet. ebXML introduces a set of internet messaging services standards that the end users can follow to exchange business documents in a secure and reliable way.

Previous releases of TIBCO BusinessConnect ebXML Protocol implemented ebXML/ebMS 2.0 standard. ebMS 2.0 utilizes various XML standards and technologies such as MIME, XML, SOAP, SOAP messages with attachments, XML signature and encryption, so business documents of any format can be enveloped flexibly and exchanged securely and reliably. TIBCO BusinessConnect ebXML Protocol also adopts other ebXML standards such as ebXML Business Process Specification Schema (BPSS), ebXML Collaboration Protocol Profile and Agreement (CPPA), so the messaging services are integrated with customer business logic smoothly.

From release 6.0, TIBCO BusinessConnect ebXML Protocol adds implementation of a new ebXML messaging services standard ebMS 3.0 and OASIS AS4 Profile. See OASIS ebMS 3.0 Standard and AS4 Profile on page 2 for more information.

OASIS ebMS 3.0 Standard and AS4 Profile

The emergence of the OASIS ebMS 3.0 standard represents a leap forward in Web Services B2B messaging services. The OASIS ebMS 3.0 standard leverages many Web Services standards and forms a single comprehensive specification for defining the secure and reliable exchange of documents using Web Services.

However the ebMS 3.0 specification still contains numerous options and comprehensive alternatives for addressing a variety of scenarios for exchanging data over a Web Services platform, therefore the AS4 Profile is developed by OASIS which defines a subset of ebMS 3.0 functionality based on the “just-enough” design principles.

TIBCO BusinessConnect ebXML Protocol 6.0 implements the AS4 ebHandler Conformance Profile, which supports both Sending and Receiving roles, and for each role both message pushing and message pulling. The implementation also leverages the fundamental Web Services Standards such as SOAP 1.1, SOAP 1.2, SOAP with Attachments and WS-Security, among others.

Go to http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ to access the ebMS3 specifications and AS4 profile.

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/


TIBCO BusinessConnect ebXML Protocol Architecture | 3

TIBCO BusinessConnect ebXML Protocol Architecture

TIBCO BusinessConnect ebXML Protocol — ebMS3/AS4 Standard is the TIBCO implementation of ebXML Message Service 3.0. As a plug-in to TIBCO BusinessConnect, it is capable of handling one-way and two-way transactions.

TIBCO BusinessConnect ebXML Protocol offers advanced message processing such as duplicate detection, receipt reply pattern, time-to-live, and error handling. Its security features also enable you to carry out transactions that require authentication, authorization, integrity, privacy, and non-repudiation.

See Features on page 5 for a detailed list of the features of TIBCO BusinessConnect ebXML Protocol — ebMS3/AS4 Standard.

Figure 1 is a graphical representation of the TIBCO BusinessConnect ebXML Protocol implementation of ebMS3 components.

Figure 1 ebMS3 Components in TIBCO BusinessConnect ebXML Protocol

The previous figure shows the following conceptual parts:

• Messaging Service Interface

• Messaging Service Layer

• Transport Services

JMS or TIBCO Rendezvous(Messaging Service Interface)

Application or SOAP Processor

Reliability Module

Transport Binding or

Other SOAP Processor

ebMS3 Packaging

WSS Module

MSH

Receiving

Sending

TIBCO BusinessConnect ebXML

Protocol — ebMS3/AS4 Standard

(Messaging Service)



Messaging Service Interface

This is an abstract service interface that ebMS3-compliant applications use to interact with the messaging service layer to send and receive messages. The messaging service layer also uses this to interface with applications handling received messages.

Messaging Service Layer

The message service layer maps the abstract interface to the underlying transport services. It includes the following conceptual parts:

• ebMS3 Packaging The ebMS3 message contains ebMS3 header elements and may contain one or more payloads. See Appendix D, Public Messages, on page 159 for more information.

• Reliability Module This module includes the following functions:

— Receipt awareness

— Duplicate elimination

— Message retry

See Reception Awareness on page 18 and Duplicate Elimination on page 22 for more information.

• WSS Module This module performs all security-related functions including:

— Generation and verification of any digital signatures

— Encryption and decryption of any SOAP body and attachment

— Username/token authentication and authorization

See Security Module on page 23 for more information.

Transport Services

This part of the MSH enables transport protocols, which deliver public messages.

For the TIBCO BusinessConnect ebXML Protocol implementation of ebXML, the transport protocols available are HTTP, HTTPS, and HTTPSCA.


Features | 5

Features

The following are major features in TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 Standard:

• Conforms to the ebMS 3.0 core specification and AS4 ebHandler profile

• One-way push, one-way pull, and two-way push-and-push transactions

• Message Service Handler with receipt awareness and duplicate elimination

• Receipt reply pattern specified by ebMS3/AS4: callback, response

• Temporarily stores the outbound messages to be pulled later by the trading partner; Multiple Partitioning Channel (MPC) is supported for Pull Request

• Authentication, non-repudiation, and XML digital signatures for both user messages and signal messages by following the WSS security standard

• WSS Username/token as an alternative approach for authentication by following the WSS usernameToken profile

• WSS Username/token used for authorization against a particular MPC

• Payload encryption using XML encryption by following the WSS security standard

• Digital signature and encryption of attachments by following the WSS SOAP Message with Attachments standard

• Compressed attachments

• Sets the ebMS3 message customer properties for payload and attachments

• SOAP and MIME (SOAP with attachments) public message packaging

• Generates standard errors defined in the ebMS3 core specification and AS4 profile

• HTTP and HTTPS (also with client authentication) transport protocols

• Support for integration with TIBCO ActiveMatrix BusinessWorks

• Advisory signals to private processes for receipts or error signals received from the trading partner

• The ability to specify certain timing constraints, such as how long to wait for a response from a private process

• Audit and non-repudiation information stored in database



Certain database tables enable centralized storage of critical information. See the TIBCO BusinessConnect Trading Partner Administration for more information. You can use the Log Viewer to view these records.


| 7

Chapter 2 Process Flows and Functionality

This chapter describes process flows and relevant functionality when ebMS3 is used by TIBCO BusinessConnect ebXML Protocol for business transactions.

Topics

• Public and Private Messages, page 8

• Processing ebMS3 Transactions, page 10

• Message Partition Channels, page 16

• Reception Awareness, page 18

• Receipt Reply Pattern, page 20

• Duplicate Elimination, page 22

• Security Module, page 23

• Error Handling, page 26


8 | Chapter 2 Process Flows and Functionality

Public and Private Messages

In an ebMS3 transaction, two partners exchange business documents over the Internet based on the pre-defined rules of ebXML. These rules are defined by a set of processing modes (P-Mode). ebXML specifies what message formats and transport protocols the partners have agreed to use, among other options. See Anatomy of a Business Protocol in the TIBCO BusinessConnect Trading Partner Administration for more information on the partner agreement. The agreement reached between the two trading partners are represented by Agreement Reference ID, or AgreementRef.

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

• Private messages

• Public messages

Private Messages and Processes

Private messages are exchanged between private processes and TIBCO BusinessConnect ebXML Protocol. Private messages carry business documents, including request, response, or notification documents, or alternatively, advisory and error signals. For a detailed description of TIBCO BusinessConnect ebXML Protocol private messages, see Private Process Message Formats on page 73.

Private processes are an enterprise’s back office system that generates or processes business documents, and conducts business logic. TIBCO BusinessConnect Palette, which works with TIBCO ActiveMatrix BusinessWorks, can act as the interface of private processes to handle conversion of internal data to and from the formats acceptable to the BusinessConnect servers, that is the public process.

• Outbound The BusinessConnect Palette working in private processes converts internal data into business documents in the formats acceptable to the public process. In this case, the private processes are the message producer in ebMS3’s terminology.

• Inbound The BusinessConnect Palette working in private processes receives business documents in the formats defined by the public processes, converts them to internal company formats, and processes the data or forwards to other internal resources for processing. In this case, the private processes are the message consumer in ebMS3’s terminology.


Public and Private Messages | 9

See Chapter 8, Private Processes, on page 71 for more information on private processes.

Public Messages and Processes

TIBCO BusinessConnect ebXML Protocol works inside the BusinessConnect Servers that act as the public process and exchanges documents with a trading partner over the Internet using the message formats and protocols defined by the ebXML Message Service specification, or called ebXML Messaging Service Handler (MSH), in ebXML’s terminology. For detailed information on public processes, see Appendix D, Public Messages, on page 159.

An ebMS3 public message is a SOAP message that contains:

• SOAP header contain ebMS message header and security header

• SOAP body can be used to encapsulate user payload

• Attachments encapsulate supplemental documents of arbitrary formats

An ebMS3 message can be a user message or a signal message.

See ebMS3 Public Message Structure on page 160 for more information.

User Message

An ebMS3 user message is an ebMS message that contains a user message unit. In other words, it contains an eb:UserMessage element as a child of eb:Messaging. An ebMS user message carries business data. It is submitted by a producer and is subject to delivery to a consumer.

Signal Message

An ebMS3 signal message is an ebMS message that contains a signal message unit. An ebMS signal message does not carry any business data. It is not intended to be delivered to a message consumer.

There are three types of signal message specified in ebMS 3.0: the error signal message, the MSH receipt signal message, and the pull request signal message.



Processing ebMS3 Transactions

This section describes how TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 standard processes simple transactions.

TIBCO BusinessConnect ebXML Protocol, conforming to the ebMS3/AS4 standard, can process the following transactions:

• One-Way Push Transactions

• One-Way Pull Transactions

• Asynchronous Two-Way Push-and-Push Transactions

One-Way Push Transactions

Figure 2 shows how TIBCO BusinessConnect ebXML Protocol processes a one-way push transaction with MSH receipt required for the request message. In this figure, both the initiator MSH and responder MSH are implemented by TIBCO BusinessConnect for simplicity and convenience of description.

Figure 2 Processing One-Way Push Transactions

The following is description about the previous figure.

1. The initiator private process sends a request to the initiator BusinessConnect server.

2. The initiator BusinessConnect server encapsulates the business request into an ebMS3 user message (including the necessary security handling), and sends to the responder BusinessConnect server.

Initiator Private Process

(Message Producer)

Responder Private Process

(Message Consumer)

Request Message

Public Request Message

MSH Receipt

(User Message)

(Signal Message)

Receipt Advisory

Request Message

1

2

3

4

5

Initiator Public Process

(BusinessConnect)

Responder Public Process

(BusinessConnect)


Processing ebMS3 Transactions | 11

3. The responder BusinessConnect server unpackages the received ebMS3 message, applies security handling (for example, signature verification, decryption, authentication, authorization and so on), and sends the business documents, including the attachments, to the responder private process.

4. The responder BusinessConnect server sends an MSH receipt back to the initiator BusinessConnect server indicating that the message has been received and successfully processed. The MSH receipt can be sent synchronously or asynchronously.

5. The initiator BusinessConnect server publishes an advisory message to the initiator private process indicating that the request has been accepted by the responder side.

One-Way Pull Transactions

Figure 3 shows how TIBCO BusinessConnect ebXML Protocol processes a one-way pull transaction with MSH Receipt required for the response message. In this figure, both the initiator MSH and responder MSH are implemented by TIBCO BusinessConnect for simplicity and convenience of description.

Figure 3 Processing One-Way Pull Transactions


Message

Pull Request

(Signal Message)

MSH Receipt (async)

(User Message)

StoreAnd

Forward

Store

Response Message

Receipt Advisory(Signal Message)

Pull Request

Response Message

1

23

4

5

6

7

8

Responder Private Process

(Message Producer)

Initiator Private Process

(Message Consumer)

Initiator Public Process

(BusinessConnect)

Responder Public Process

(BusinessConnect)



1. The responder private process (message producer) sends the business document in the format of private process message to the responder BusinessConnect server.

2. The responder BusinessConnect server receives the business document and encapsulates it into an ebMS3 user message after applying the necessary security handling, and stores it to a temporary storage named Store-and-Forward.

3. The initiator private process (message consumer) sends a pull request in the format of private process message to the initiator BusinessConnect server.

4. The initiator BusinessConnect server generates an ebMS3 pull request signal message, which relays the pull request to the responder BusinessConnect server.

5. The responder BusinessConnect server retrieves a qualified user message from the Store-and-Forward storage, and then sends the message in a pull response to the initiator BusinessConnect server.

6. The initiator BusinessConnect server unpackages the user message, including applying the necessary security handling (for example, signature verification, decryption, and authentication), and sends the extracted business document to the initiator private process.

7. The initiator BusinessConnect server sends an MSH receipt to the responder BusinessConnect server asynchronously indicating that the message has been processed successfully.

8. Upon receiving the MSH receipt, the responder BusinessConnect server publishes an advisory message to the responder private process indicating that the response has been accepted by the initiator side.

Asynchronous Two-Way Push-and-Push Transactions

TIBCO BusinessConnect ebXML Protocol can process a two-way push-and-push transaction. A two-way push-and-push transaction can be considered a combination of two one-way push transactions in opposite directions, with the second one (the response message) referring to the first one using a special message header field eb:RefToMessageId. In a two-way push-and-push transaction, the response message is sent asynchronously, and the MSH receipt (if required) for the request message and response message can be sent synchronously or asynchronously.

Figure 4 shows how TIBCO BusinessConnect ebXML Protocol processes an asynchronous two-way push-and-push transaction in which MSH receipt (required both for the request message and the response message) can be sent synchronously or asynchronously.



In this figure, both the initiator MSH and responder MSH are implemented by TIBCO BusinessConnect for simplicity and convenience of description.

Figure 4 Processing Asynchronous Two-Way Push-and-Push Transactions


1. The initiator private process sends the request business document in the format of private process message to the initiator BusinessConnect server.

2. The initiator BusinessConnect server encapsulates the business request into an ebMS3 request user message and sends to the responder BusinessConnect server. The necessary security handling can be applied to the user message.

3. The responder BusinessConnect server unpackages the request user message with the necessary security handling being applied, and then sends the extracted request business documents to the responder private process.

4. The responder BusinessConnect server sends an MSH receipt back to the initiator BusinessConnect server synchronously or asynchronously. Whatever the receipt is sent back synchronously or asynchronously, the original transport channel connection (HTTP or HTTPS) is closed after this.

5. The initiator BusinessConnect server sends a receipt advisory message to the initiator private process indicating that the request message has been received and processed successfully by the responder.

6. The responder private process sends the response business document in the format of private process message to the responder BusinessConnect server.

InitiatorPrivate Process

Request Message

Public Response Message (async)

(User Message)

MSH Receipt (sync/async)

(User Message)


Receipt Advisory

Initiator BusinessConnect

ResponderPrivate Process

Responder BusinessConnect

(Signal Message)

Request Message

Response Message

MSH Receipt (sync/async)

(Signal Message)

1

2

4

3

6

9

7

5

Response Message

8

Receipt Advisory

10



7. The responder BusinessConnect server packages the business message into another ebMS3 user message with the necessary security handling being applied, and then sends a response user message to the initiator BusinessConnect server asynchronously because the original transport channel initiated by the initiator BusinessConnect server was already closed.

8. The initiator BusinessConnect server unpackages the response user message with the necessary security handling being applied, and then sends the extracted response business documents to the initiator private process.

9. The initiator BusinessConnect server sends an MSH receipt to the responder BusinessConnect server synchronously or asynchronously.

10. The responder BusinessConnect server sends a receipt advisory message to the responder private process indicating the response message has been received and processed by the initiator successfully.

Processing Signals

This section describes how TIBCO BusinessConnect ebXML Protocol processes signal messages. Three types of signal messages are specified in ebMS3:

• Error Signal

• Receipt Signal

• Pull Signal

Error Signal

TIBCO BusinessConnect ebXML Protocol sends error signals to the trading partner if an error occurs when processing inbound messages.

See Error Handling on page 26 for more information on error messages.

Receipt Signal

You can set TIBCO BusinessConnect ebXML Protocol to require MSH receipt. The MSH receipt message (if required) is used to inform a message sender that the message has been received to achieve the reliability feature called Reception Awareness defined in the ebMS3 specification. Note that in the processing flow of TIBCO BusinessConnect ebXML Protocol, it sends out the MSH receipt message after it successfully receives and processes the user message.

You can set TIBCO BusinessConnect ebXML Protocol to send MSH receipt for a push request synchronously and send the MSH receipt for a push response asynchronously, and vice versa.



Non-repudiation of Receipt

If the original user message is digitally signed, it can be configured so that the receipt can contain a well-formed ebbpsig:NonRepudiationInformation element, which contains the digital digest of the original user message for the purpose of non-repudiation.

See Receipt Reply Pattern on page 20 for more information about the reply pattern for ebMS3 transactions.

Pull Signal

You can use TIBCO BusinessConnect ebXML Protocol to send a pull request out to pull a user message from a message producer on a trading partner side, or process a pull request from a trading partner.

The pull signal message can contain the MPC information to indicate from which queue the message is to be pulled, as well as the authorization token which is used by the responder side to authorize the request for the particular MPC.

See Message Partition Channels on page 16 and One-Way Pull Transactions on page 11 for more information about pull signal messages.



Message Partition Channels

Message Partition Channels (MPCs) allow for partitioning the flow of messages from a sending MSH to a receiving MSH into several flows, then the flows can be controlled separately and consumed differently in terms of transfer priorities.

In TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 standard, MPCs are used in Pull transactions, so messages can be pulled from different queues identified by MPCs.

Figure 5 shows an example of the MPC work flow for one-way pull transactions.

Figure 5 MPC for One-Way Pull Transactions

1. The producer submits a user message to the responding MSH, intended for the consumer on the initiator side. MPC value can be specified for this user message. If no MPC is specified, the user message will be considered belonging to the default MPC.

In the current implementation, a username associated with a particular trading partner has to be submitted together with the user message to be stored for pulling, so this message can only be pulled by this user. MPC and the username will be stored in Store-and-Forward together with the message.

2. The consumer sends a pull signal message by the initiating MSH. The pull request must carry a WSS Username/token which is used to identify from which trading partner the pull request is initiated, and also to authorize the accessibility to a particular MPC.

If no MPC is specified in the pull signal message, the message is supposed to be pulled from the default MPC channel of this particular user.

Submit User Message

Producer Responding MSH Initiating MSH Consumer

Message Partition Channel (MPC)

Get MPC

User Message

Pull (MPC)

User Message


Message Partition Channels | 17

If MPC is specified in the pull signal message, the message is supposed to be pulled from the specified MPC channel of this particular trading partner. Therefore, it will be authorized on the responder side for pulling messages from this particular MPC of this particular user.

3. According to the pull request signal received, the responding MSH selects a previously submitted message from Store-and-Forward, and sends it over the response to the initiating MSH. In this process, the WSS Username/token and the MPC in the pull request message will be used to authorize if the user has access to the messages in this particular MPC.

Note: If more than one message in the MPC conform to the conditions specified by the pull request, a First-in-First-out (FIFO) policy is conducted to select the message. If no user message available in the specified MPC to be pulled, an error signal message with warning error code is sent back instead.

4. The initiating MSH receives the returned ebMS3 message, unpackages the messages (including the necessary security handling), and sends the extracted business documents to the initiator private process, the message consumer.

5. The initiating MSH can choose to send a receipt asynchronously to the responder MSH, indicating that the message has been received and processed. The receipt can also be a Non-Repudiation of receipt which contains the signed digest of the user message just being pulled.



Reception Awareness

With TIBCO BusinessConnect ebXML Protocol, you can customize the level of reliability in message delivery by requiring MSH receipt messages and retrying to send the message if the receipt message is not received in a given time. MSH receipts, when required, are used to confirm the successful delivery of messages.

To set TIBCO BusinessConnect ebXML Protocol to require MSH receipts or not in TIBCO Administrator, select BusinessConnect > Operations Editor > ebMS3 > transaction > Action and select one value from the drop-down list of the Require MSH Receipt field.

When MSH receipts are required, you can set:

• the time to wait for an MSH receipt

The length of time to wait for an MSH receipt from the trading partner. After this time expires, the action message is resent to the trading partner as many times as the maximum retries times. If the last retry fails, an error message is sent back to the private process (the message producer) indicating the failure of the delivery.

• maximum number of retries

The maximum number of times to retry sending the action message before receiving an MSH receipt.

Note: this property is not available for one-way pull transaction.

Figure 6 shows how TIBCO BusinessConnect ebXML Protocol processes a one-way push transaction with MSH receipt required for the request message.


Reception Awareness | 19

Figure 6 Message Delivery with MSH Receipt

If the initiator does not receive the receipt for a public message before the waiting time expires, it resends the message until the maximum number of retries has been reached.


BusinessConnect Server

Trading Partner

MSH Receipt


Advisory Signal

Resend Request

Request Message



Receipt Reply Pattern

TIBCO BusinessConnect ebXML Protocol enables you to define two receipt reply patterns for ebMS3 transactions: callback and response. You can select one of them in the Receipt Reply Pattern property in the Operations Editor panel.

• callback Send MSH receipts (if configured) through a separate transport channel, or called asynchronous mode. Figure 7 depicts the behavior of this mode when TIBCO BusinessConnect ebXML Protocol works as an initiator in a two-way push-and-push transaction.

Figure 7 Receipt Reply Pattern: callback

The dotted line in the previous figure indicates that the receipts are replied via a separate transport channel.



Trading Partner

Request MessagePublic Request Message

MSH Receipt (async)Advisory Signal

Public Response Message

Response Message

MSH Receipt (async)


Receipt Reply Pattern | 21

• response Send the MSH receipt (if configured) by the back-channel of the original transport, or called synchronous mode. Figure 8 depicts the behavior of TIBCO BusinessConnect ebXML Protocol when it works as the initiator in a two-way push-and-push transaction.

Figure 8 Receipt Reply Pattern: response

The solid line in the previous figure indicates that the receipts are replied via the back channel of the original message transport.



Trading Partner

Request MessagePublic Request Message

MSH Receipt (sync)Advisory Signal

Public Response Message

Response Message

MSH Receipt (sync)



Duplicate Elimination

With TIBCO BusinessConnect ebXML Protocol, you can customize the level of reliability in message delivery by detecting and eliminating duplicate messages.

To set TIBCO BusinessConnect ebXML Protocol to eliminate duplicate messages or not, select BusinessConnect > Operations Editor > ebMS3 > transaction > Action and select one value from the drop-down list of the Eliminate Duplicate Message field in TIBCO Administrator.

Duplicate detection and elimination is always supported by TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 standard both for inbound messages and outbound messages. A duplicate message can be caused by the retries of the sending side, due to the loss of the receipt used to acknowledge an original user message.

The receiving MSH keeps the record of all recently received messages, so for a newly received user message, eb:MessageInfo/eb:MessageId in the message will be checked against the record. If this message id already exists in the record, a duplication is detected and will be audit logged. This duplication status will also be reported to the receiver side’s private process (the message consumer). If duplicate elimination is configured, the duplicate user message will not be sent to the private process, but rather an error advisory will be sent to the private process.

The sending MSH also keeps the record of all business messages received from its private process. If the business message received from the private process contains a message id and this id matches one in the record, a duplication is detected. If duplication elimination is configured, this message will be rejected.


Security Module | 23

Security Module

TIBCO BusinessConnect ebXML Protocol 6.0 ebMS3/AS4 Standard supports the security module defined in the ebMS3.0 core specification and the AS4 ebHandler Profile that follow the WSS specifications.

TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 Standard supports the following security features:

• Digital Signature

• Encryption

• UsernameToken for Authentication

• PullRequest Authorization

• Transport Level Security

Digital Signature

Digital signatures are used to bind information to the identity of its originator. They can be used to provide data origin authentication, data integrity, and non-repudiation.

TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 Standard supports the following digital signature features:

• Web Services Security X.509 Certificate Token Profile

• Digital signature for SOAP header and SOAP body

— Detached signatures format as defined by the XML Signature Specification

— The entire eb:Messaging container element and the SOAP body should be included in the WSS signature when signing messages

• Digital signature for SOAP attachments

— The Attachment-Content-Only transform is used for attachment signature which follows the AS4 specification.

— All MIME body parts of the to-be-signed attachments should be included in the WSS signature, together with the entire eb:Messaging container element and the SOAP body when signing attachment.

• Digital signature for receipt (Non Repudiation of Receipt) to acknowledge signed messages.



You can set TIBCO BusinessConnect ebXML Protocol to enable the signature of request and response by selecting Operations Editor > ebMS3 > transaction > Action > General > Require Non-repudiation of Request/Response in TIBCO Administrator.

You can set TIBCO BusinessConnect ebXML Protocol to enable the signature of receipt by selecting Operations Editor > ebMS3 > transaction > Action > Receipt > Require Non-Repudiation of MSH Receipt in TIBCO Administrator.

Encryption

TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 Standard supports the following encryption features:

• Web Services Security X.509 Certificate Token Profile

• Encryption for SOAP body

Support the WSS Encryption [WSS11] specification over SOAP body when it is used to carry payloads.

• Encryption for SOAP attachments

Support the SOAP Messages with Attachments specification [SOAPATTACH] to encrypt the MIME body parts of the included payloads.

You can set TIBCO BusinessConnect ebXML Protocol to enable the document encryption by selecting Operations Editor > ebMS3 > transaction > Document > Encrypt Document in TIBCO Administrator.

UsernameToken for Authentication

As an authentication alternative, WSS Username/Password Token ([WSS11-UT]) can also be used, without the exclusiveness of Digital Signature Authentication, for inbound message authentication.

The password type of Username/token is only digest password in the current implementation for outbound messages. For inbound messages, either the digest or plain text password (normally used together with SSL transport) are accepted.

When Username/token is used for authentication, the wsse:UsernameToken element is in the “primary” security header along with other security entities such as digital signature and encryption element if they are present. This “primary” security header is supposed to be handled by the security module of the receiving MSH, so it will not have the @role="ebms" attribute.


Security Module | 25

You can set TIBCO BusinessConnect ebXML Protocol to enable the Username/token for authentication by selecting Operations Editor > ebMS3 > transaction > Action > General > Require UsernameToken Authentication of Request/Response in TIBCO Administrator.

PullRequest Authorization

WSS Username/Password Token ([WSS11-UT]) can also be used with Pull transaction, to authorize a Pull Request for the accessibility to a specific MPC. If the MPC is missing, the request is supposed to pull from the default channel.

The username and password in the PullRequest are used for authorizing if an external user, who is associated with a trading partner, has the access to pull messages from a particular MPC. If the authorization succeeds, the message will be pulled from this particular channel belonging to this partner in message storage.

When Username/token is used for MPC authorization, it will be put in a “secondary” security header, and is supposed to be handled by the ebMS module on the receiving MSH, so this security header will have the @role="ebms" attribute in the message.

See Message Partition Channels on page 16 for more information.

Transport Level Security

The transport level security such as SSL over HTTP/HTTPS is also supported by the protocol.

See TIBCO BusinessConnect documentation for more information on the transport level security features.



Error Handling

TIBCO BusinessConnect ebXML Protocol sends error signals to the trading partner whenever it encounters an error while processing the inbound ebMS3 action or signal messages (see Processing Signals on page 14). Reasons for an error message include, but are not limited to the following:

• A delivery failure occurred.

• The ebMS3 message envelope is not well-formed, cannot be validated on either XML, SOAP, or ebXML layer, fails to resolve external references, etc.

• The transaction is not authorized.

• The ebMS3 message data does not match up with the settings in the TIBCO BusinessConnect ebXML Protocol configuration store, such as settings for trading partners, digital signatures, encryption, non repudiation of receipt, or the mis-match of agreement reference, p-mode ID and so on.

• The message did not pass security checks, such as digital signature verification failure, failed to be decrypted, and so on.

When TIBCO BusinessConnect ebXML Protocol receives an error message from the trading partner in response to an outbound message, it updates the private process which is the message producer by publishing the following private messages:

• In case of trading partner error while processing request message: an ae/ebMS3/InitiatorResponse message that packages the error message in the response field. See Inbound Response Format on page 81 for more information.

• In case of trading partner error while processing response message: if an ae/ebMS3/ResponderAck message has not already been sent to the private process, an ae/ebMS3/ResponderAck message with an error code in the statusCode field. See Response Acknowledgment Format on page 90 for more information.

• An ae/ebMS3/Advisory message on the error subject. See Error Message Format on page 95 for more information.

All the error messages are sent synchronously.


Error Handling | 27

Error Types

An error generated by TIBCO BusinessConnect ebXML Protocol can be of one of the following types:

• SOAP Faults

• AS4 Errors

• ebMS Errors

• Internal Errors

SOAP Faults

The SOAP faults generated by TIBCO BusinessConnect ebXML Protocol are errors against the SOAP specification.

Go to http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.html for more information.

AS4 Errors

The AS4 Errors generated by TIBCO BusinessConnect ebXML Protocol are errors against the AS4 specification.

Go to http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/cs03/AS4-profile-v1.0-cs03.html for more information.

ebMS Errors

The ebMS errors generated by TIBCO BusinessConnect ebXML Protocol are errors occurred to the ebMS3 specification.

Go to http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.html for more information.

Internal Errors

The internal errors generated by TIBCO BusinessConnect ebXML Protocol are errors occurred during the one-way push, one-way pull, and two-way push-and-push transactions which are not defined by either SOAP, ebMS, or AS4 specifications.

See Appendix A on page 141 for a list of all internal errors.

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.html


http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/cs03/AS4-profile-v1.0-cs03.html

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/cs03/AS4-profile-v1.0-cs03.html




| 29

Chapter 3 Preparing to Use TIBCO BusinessConnect

ebXML Protocol

This chapter describes the preliminary information you need to configure your BusinessConnect server for your ebMS3 transactions. It also gives the instructions for configuring some of this information in your BusinessConnect server. You must perform all the tasks in this chapter prior to configuring BusinessConnect participants with ebXML protocol.

Topics

• Exchanging Information with Your Trading Partner, page 30

• Configuring Your BusinessConnect Server, page 31


30 | Chapter 3 Preparing to Use TIBCO BusinessConnect ebXML Protocol

Exchanging Information with Your Trading Partner

Before you start conducting e-commerce with your trading partner, you must exchange the following information:

• Party ID and PartyID Type The Party IDs are how you and your trading partner identify each other. The identify may belong to a business domain which is called PartyID Type in ebMS3 standard. The PartyID and PartyID Type of both sides will be present in the ebMS3 user messages exchanged between the two parties. The trading partner can choose not to use PartyID Type, in which case the PartyID must be the format of valid URI.

• Server URLs You and your trading partner need to know each other’s server URL to conduct e-commerce transactions.

Server URLs for TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 Standard follow the formats below:protocol://hostName:portNumber/dmz/ebMS3

The host name and port number are determined by your IT department. See Transports on page 31 for how to set the inbound transport for receiving messages from your trading partner.

For example:

http://www.myhost.com:6700/dmz/ebMS3

https://www.myhost.com:6705/dmz/ebMS3

• Public Certificates In order to use HTTPS for your ebMS3 transactions, as well as utilize digital signatures for document authentication, or encryption for data security you must also exchange public certificates. TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 Standard supports PKI X.509 Certificate Token for public certificate.

• P-Mode and Agreement Reference You and your trading partner need to agree on the processing mode (referenced by P-Mode ID) and the agreement reference (AgreementRef) that are used to guide the transactions.

• MPC You and your trading partner need to agree on the MPC if they support message prioritization by using Multiple Partitioning Channel, and the Username/tokens used to authorize the accessibilities to each channel.


Configuring Your BusinessConnect Server | 31

Configuring Your BusinessConnect Server

You must perform a few tasks in the BusinessConnect console in TIBCO Administrator before you can successfully configure a BusinessConnect participant with ebXML protocol.

Transports

Before you can configure a BusinessConnect participant’s transport protocol, you must enable the transport protocols. TIBCO BusinessConnect ebXML Protocol supports the following two types of transports: HTTP and HTTPS (with or without client authentication).

For more information on how to enable the outbound transport to send ebMS3/AS4 messages to your trading partner, see "Chapter 11 HTTP, HTTPS, and HTTPSCA Transports" of TIBCO BusinessConnect Trading Partner Administration.

For more information on how to configure the transport services to allow the inbound connections from your trading partner, see "Chapter 4 Gateway Services" of TIBCO BusinessConnect Gateway Server Administration.

Domains

If the Party IDs you and your trading partners used to identify each other belong to a business domain, which is also called PartyID Type in ebMS3 standard, you have to define this domain in TIBCO BusinessConnect server. This domain, when chosen to be used for a trading partner, will present as the eb:PartyID/@type attribute in the ebMS3 message sent to the partner.

Follow the instructions below to add a domain:

1. In TIBCO Administrator, expand BusinessConnect > System Settings in the left panel.

2. Click Metadata Type Configuration in the right panel.

3. Click Domains.

4. Click New.

5. Type the name of the domain you wish to use in the Domain Name field.

6. Click Save.

7. Click Done twice.


32 | Chapter 3 Preparing to Use TIBCO BusinessConnect ebXML Protocol

External Users

If your trading partner will use WSS:UsernameToken to authenticate the message they send to you, or use WSS:UsernameToken to authorize a pull request issued by them, you need to define the external users associated with this trading partner.

See "Chapter 5 User Access Management" of TIBCO BusinessConnect Trading Partner Administration for how to create an external user and associate this user with a particular trading partner.


| 33

Chapter 4 Managing ebMS3 Operation Definitions

This chapter explains how to manage ebMS3 operation definitions in the Operations Editor panel.

Topics

• Managing ebMS3 Operation Definitions, page 34

• Adding Transactions, page 35

• Exporting Transactions, page 50

• Importing Transactions, page 51


34 | Chapter 4 Managing ebMS3 Operation Definitions

Managing ebMS3 Operation Definitions

The Operations Editor panel organizes ebMS3 operation definitions, which are called transactions in containers of various levels. Each of the operation definitions consists of many property definitions, which define the process mode of a particular business transaction. A process mode is called P-Mode in ebMS3 terminology and is referenced by P-Mode ID. In Operations Editor, transactions defined by the same organization are grouped into the same organization container (for example, RosettaNet.org). Within an organization container, they are organized into business process containers (for example, 3A4). Then, transactions further organized by their document version into version containers (for example, 1.1). A transaction is the most basic unit for an ebMS3 transaction in the Operations Editor panel (for example, Create Purchase Order).

Before you can use ebMS3 in business transactions, you must add the transactions in the Operations Editor panel in TIBCO Administrator and configure each of them accordingly. See Adding Transactions on page 35 for more information.

After you have added the transactions into the Operations Editor panel, you can export them to a file. When you upgrade or reinstall TIBCO BusinessConnect ebXML Protocol, you can simply import the data into the Operations Editor panel. See Exporting Transactions on page 50 and Importing Transactions on page 51 for more information.

While you can give a container any name you wish, it is recommended that you follow the naming convention described above in order to ensure that both you and your trading partner are using the same naming conventions for your ebMS3 transactions.


Adding Transactions | 35

Adding Transactions

The section provides the instructions on adding transactions in the Operations Editor panel, which consists of the following tasks:

• Task A, Adding Organization Containers, page 35

• Task B, Adding Business Process Containers, page 35

• Task C, Adding Version Containers, page 35

• Task D, Adding Transactions, page 36

Task A Adding Organization Containers

Follow the instructions below to add an organization container:

1. In TIBCO Administrator, expand BusinessConnect > Operations Editor in the left panel.

2. Select ebMS3 from the Protocol list in the right panel.

3. Click New Organization.

4. Type the organization name in the Name field.

5. Optionally add description in the Description field, and the business process agency id in the Business Process Agency ID field.

6. Click Save.

Task B Adding Business Process Containers

Follow the instructions below to add a business process container:

1. Click the radio button for the organization container you created in Task A.

2. Click New Business Process.

3. Type the name of the business process in the Name field, as defined by the organization you specified in Task A.

4. Click Save.

Task C Adding Version Containers

Follow the instructions below to add a version container:

1. Click the radio button for the version container you created in Task B.

2. Click New Version.



3. Type the version of the business transaction in the Name field.

4. Click Save.

Task D Adding Transactions

Follow the instructions below to add a transaction:

1. Click the radio button for the version container you created in Task C.

2. Click New Transaction.

3. Select either One-Way, Pull or Two-Way from the Operation Type drop-down list.

4. Click OK.

5. Configure the transaction in each tab.

For more information about how to configure transactions, see Transaction Properties on page 36.

6. Click Save.

Transaction Properties

This section describes each field in one-way transactions, two-way transactions, and pull transactions respectively.

One-Way Transaction Properties

If you specify One-Way in Task D, you see the One-Way Transaction and Request Action tabs when you configure the transaction in the Edit Transaction panel. A one-way operation type can be used for guiding one-way push transaction, or can be used for guiding how a message is prepared and stored in Store-and-Forward, so it can be pulled by another one-way pull transaction.

Table 3 describes each field in the One-Way Transaction tab.

You can override certain transaction settings when configuring protocol bindings for a business agreement. See Operation Settings Tab on page 64 for more information.

Table 3 One-Way Operation Type: One-Way Transaction Tab

Field Description

General Tab



Name The displayed name of the transaction.

Description (Optional) A short description of the transaction.

Roles Tab

Initiating Role The role of the initiator in this transaction. This field is mapped to the respective Role element in the public user message’s eb:PartyId/eb:From element.

Responding Role

The role of the responder in this transaction. This field is mapped to the respective Role element in the public user message’s eb:PartyId/eb:To element.

Service Information Tab

Service The service that acts upon this message, as defined by ebMS. This field is mapped to the Service element in the public message’s SOAP header.

You must specify a URI in this field if the Service Type field is empty.

Service Type The service type, as defined by ebMS. This field is mapped to the Type attribute in the public message’s Service element.

You must specify a URI in the Service field if this field is empty.

P-Mode ID The identifier for the processing mode defined by this transaction. It is also called operation definition in TIBCO BusinessConnect. This is the default P-Mode ID for this P-Mode. You can override the P-Mode ID using a special P-Mode Id agreed between you and your trading partner when configuring protocol bindings for a business agreement to identify the specific P-Mode used between you and your trading partner for guiding this particular transaction.

Note: The combination of Service, Service Type, the Request Action name (introduced in the next section), and P-Mode ID is the identification of a business transaction. These values are present in user messages, which will be used by the receiver to recognize which P-Mode (or operation type) is to be used to process a received user message.

Document Tab

Encrypt Document

Checking this checkbox to encrypt the outbound document. When this is checked, it is also required that the inbound message of this operation should be encrypted.

Table 3 One-Way Operation Type: One-Way Transaction Tab (Cont’d)

Field Description



Table 4 describes each field in the Request Action tab

Compress Document

Checking this checkbox requires that the outbound documents of this operation should be compressed. When this is checked, the contents of each attachment in the message will be compressed.

Note: This option is used only to compress attachments, not to compress messages. When a message does not include attachments, the message will not be compressed even if you check this checkbox.

Table 3 One-Way Operation Type: One-Way Transaction Tab (Cont’d)

Field Description

Table 4 One-Way Operation Type: Request Action Tab

Field Description

General Tab

Name The name of the action.

Description (Optional) A description of the action.

Direction The direction of this action.

Require Non-repudiation of Request

Require the action message to be digitally signed for non-repudiation. If this checkbox is selected, and then TIBCO BusinessConnect ebXML Protocol behaves as follows:

• Signs the outbound action message and stores the message in the non-repudiation log.

• Requires that the inbound action message of this operation is also digital signed; if it is not signed, then the message is considered invalid and an error message should be replied back.



Require UsernameToken Authentication of Request

Require the action message to contain the WSS:UsernameToken element for authentication. If this checkbox is selected, then TIBCO BusinessConnect ebXML Protocol behaves as follows:

• Sends the outbound action message with WSS:UsernameToken where the username and password are provided by the private process (the message producer).

• Requires that the inbound message of the same operation should also carry the WSS:UsernameToken element to be used for inbound message authentication. If the inbound message does not have the WSS:UsernameToken element, the message will be rejected with an error message being replied to the trading partner.


The mode in which the receipt signals are to be replied. The options are:

• callback The MSH receipt signals are sent back in a separate transport channel, which is also called asynchronous mode. The original transport channel is closed after the message is received by the receiving server.

• response The MSH receipt signals are sent back through the back channel of the original transport, which is also called synchronous mode.

See Receipt Reply Pattern on page 20 for more information.

Table 4 One-Way Operation Type: Request Action Tab (Cont’d)

Field Description



Eliminate Duplicate Message

Messages that are considered duplicated will be eliminated. BusinessConnect ebXML Protocol keeps the record of recent sent and received messages in database table. A message is considered duplicated if its message id matches one of the messages in record. BusinessConnect ebXML Protocol checks the messages received from private process on sending side, or the messages received from trading partner on receiving side for duplications. The options are:

• never Do not eliminate duplicate messages. If this option is selected, messages that are found to be duplicated will not be eliminated. This applies to both the messages received from private process on outbound side, or the messages received from trading partner on inbound side.

• always Always eliminate duplicate messages. If this option is selected, the messages that are found to be duplicated will be eliminated, meaning they will not be sent out, or delivered to its destination. This applies to both inbound and outbound side.

• perMessage This only applies on outbound side. Once it's chosen, the dupElimination property in the messages sent from private process determines whether the message is to be eliminated if it's considered duplicated. This gives the user more flexibility for controlling this behavior on per message bases.

Receipt Tab

Require MSH Receipt

Require the MSH receipt for the action message. This applies on message receiving side to determine whether a receipt is to be created and replied to the message sending side.

On message sending side, the sending MSH will expect a receipt signal to be replied back if this is enabled, so the Reception Awareness feature is achieved. If the receipt is not received within a period of time, the original message could be resent.The options are:

• never Do not generate receipt signal for the received action message.

• always Always generate receipt signal for the received action message.

Time to Wait for MSH Receipt (min.)

The length of time to wait for an MSH receipt signal from the trading partner after an action message has been sent out. After this time expires, the action message is resent to the trading partner as many times as specified in the Maximum Number of Retries field. After the last retry attempt, TIBCO BusinessConnect ebXML Protocol sends an error to the trading partner.


Field Description



Pull Transaction Properties

If you specify Pull in Task D, you see the Pull Transaction, Pull Request Action, and Pull Response Action tabs when you configure the transaction in the Edit Transaction panel.

Table 5 describes each field in the Pull Transaction tab

Maximum Number of Retries

The number of times to retry sending the action message before receiving an MSH receipt.

Require Non-repudiation of MSH Receipt

Require the MSH receipt to be digitally signed and contains the digital digest of the received message. This applies on the message receiving side.

On message sending side, the replied receipt signal will be checked if it's signed properly, and the digital digest contained in the receipt will be matched with the preserved digest of the original message for data integrity.


Field Description


The tibco.com/EBMS Pull Request/1.0/Pull Request Pull Request operation is pre-defined with the installation of the product and activation of ebXML protocol. This is a fixed operation which is used for guiding the processing of inbound Pull Request and cannot be removed. However you can override it in protocol bindings of business agreement.

Table 5 Pull Operation Type: Pull Transaction Tab

Field Description

General Tab



Roles Tab

Initiating Role The role of the initiator in this transaction.



Table 6 describes each field in the Pull Request Action tab

Responding Role The role of the responder in this transaction. Unlike the one-way push transaction, the Initiator Role and Responding Role properties will not be present in the Pull Request and Response messages.


Service The service that acts upon this message. Unlike the one-way push transaction, the service and Service Type properties will be present in the Pull Request messages.

Service Type The service type.

P-Mode ID The identifier for the processing mode defined by the transaction. Unlike the one-way push transaction, the P-Mode ID of one-way pull transaction will not be present in the Pull Request messages.

Table 5 Pull Operation Type: Pull Transaction Tab (Cont’d)

Field Description

Table 6 Pull Operation Type: Pull Request Action Tab

Field Description

General Tab




Max.Response Wait Time (min.)

The maximum length of time to wait for the response message from the trading partner, counting from the time the pull request is sent. If this time expires, TIBCO BusinessConnect ebXML Protocol sends an ae/ebMS3/Advisory message on the error subject.



Table 7 describes each field in the Pull Response Action tab

Require Non-repudiation of Request

Require the pull request message to be digitally signed for non-repudiation. If this checkbox is selected, and then TIBCO BusinessConnect ebXML Protocol behaves as follows:




The receiver of the action message must eliminate duplicate messages. TIBCO BusinessConnect ebXML Protocol can remove duplicates of action messages that are kept in persistent storage. For Pull Request, this property only applies to outbound side, because there is no message id information in an inbound Pull Request message. The options are:

• never Do not eliminate duplicate messages.

• always Always eliminate duplicate messages.

• perMessage If this option is selected, then TIBCO BusinessConnect ebXML Protocol handles duplicate elimination according to the definition of the message.

Table 6 Pull Operation Type: Pull Request Action Tab (Cont’d)

Field Description

Table 7 Pull Operation Type: Pull Response Action Tab

Field Description

General Tab






Two-Way Transaction Properties

If you specify Two-Way in Task D, you see the Two-Way Transaction, Request Action, and Response Action tabs when you configure the transaction in the Edit Transaction panel. A two-way transaction can be considered two associated One-Way Transaction, with the second transaction being the response of the first one. So the properties of the two-way transaction are almost the same as the one-way transaction.

Receipt Tab

Require MSH Receipt

Require the MSH receipt for the action message. This applies on message consumer side (the pulling side or the Pull Request initiator side) to determine whether a receipt is to be created and replied to the message sending side.

On message producer side (or the Pull Transaction responder side), the sending MSH will expect a receipt signal to be replied back if this is enabled, so the Reception Awareness feature is achieved. However, there will be no resend occurred if the receipt is not received, because the message was pulled from the message producer side. The options are:




The length of time to wait for an MSH receipt from the trading partner. After this time expires, TIBCO BusinessConnect ebXML Protocol sends an error to the trading partner. However, there will be no resend occurred because the message was pulled by the consumer side.


Require the MSH receipt to be digitally signed and contain the digest of the message that has been pulled. 6

Table 7 Pull Operation Type: Pull Response Action Tab (Cont’d)

Field Description




Table 8 describes each field in the Two-Way Transaction tab

Table 8 Two-Way Operation Type: Two-Way Transaction Tab

Field Description

General Tab



Roles Tab

Initiating Role The role of the initiator in this transaction. This field is mapped to the respective Role element in the public user message’s eb:PartyId/eb:From element.

Responding Role The role of the responder in this transaction. This field is mapped to the respective Role element in the public user message’s eb:PartyId/eb:To element.


Service The service that acts upon this message, as defined by ebMS. This field is mapped to the Service element in the public message’s SOAP header.

You must specify a URI in this field if the Service Type field is empty.

Service Type The service type, as defined by ebMS. This field is mapped to the Type attribute in the public message’s Service element.

You must specify a URI in the Service field if this field is empty.

P-Mode ID The identifier for the processing mode defined by the transaction. It is also called operation definition in TIBCO BusinessConnect. This is the default P-Mode ID for this P-Mode. You can override the P-Mode ID using a special P-Mode Id agreed between you and your trading partner when configuring protocol bindings for a business agreement to identify the specific P-Mode used between you and your trading partner for guiding this particular transaction.

Note: The combination of Service, Service Type, the Request Action name (introduced in the next section), and P-Mode ID is the identification of a business transaction. These values are present in user messages, which will be used by the receiver to recognize which P-Mode (or operation type) is to be used to process a received user message.



Table 9 describes each field in the Request/Response Action tab

Document Tab

Encrypt Document Checking this checkbox to encrypt the outbound document. When this is checked, it is also required that the inbound message of this operation should be encrypted.

Compress Document

Checking this checkbox requires that the outbound documents of this operation should be compressed. When this is checked, the contents of each attachment in the message will be compressed.

Note: This option is used only to compress attachments, not to compress messages. When a message does not include attachments, the message will not be compressed even if you check this checkbox.

Table 8 Two-Way Operation Type: Two-Way Transaction Tab (Cont’d)

Field Description

Table 9 Two-Way Operation Type: Request/Response Action Tab

Field Description

General Tab




Max.Response Wait Time (min.)

The maximum length of time to wait for the response message from the trading partner, counting from the time the action message is sent. If this time expires, TIBCO BusinessConnect ebXML Protocol sends An ae/ebMS3/Advisory message on the error subject.

Require Non-repudiation of Request/Response

Require the action message to be digitally signed for non-repudiation. If this checkbox is selected, and then TIBCO BusinessConnect ebXML Protocol behaves as follows:





Require UsernameToken Authentication of Request/Response

Require the action message to contain the WSS:UsernameToken element for authentication. If this checkbox is selected, then TIBCO BusinessConnect ebXML Protocol behaves as follows:

• Sends the outbound action message with WSS:UsernameToken where the username and password are provided by the private process (the message producer).

• Requires that the inbound message of the same operation should also carry the WSS:UsernameToken element to be used for inbound message authentication. If the inbound message does not have the WSS:UsernameToken element, the message will be rejected with an error message being replied to the trading partner.


The mode in which the receipt signals are to be replied. The options are:

• callback The MSH receipt signals are sent back in a separate transport channel, which is also called asynchronous mode. The original transport channel is closed after the message is received by the receiving server.

• response The MSH receipt signals are sent back through the back channel of the original transport, which is also called synchronous mode.

See Receipt Reply Pattern on page 20 for more information.

Table 9 Two-Way Operation Type: Request/Response Action Tab (Cont’d)

Field Description




Messages that are considered duplicated will be eliminated. BusinessConnect ebXML Protocol keeps the record of recent sent and received messages in database table. A message is considered duplicated if its message id matches one of the messages in record. BusinessConnect ebXML Protocol checks the messages received from private process on sending side, or the messages received from trading partner on receiving side for duplications. The options are:

• never Do not eliminate duplicate messages. If this option is selected, messages that are found to be duplicated will not be eliminated. This applies to both the messages received from private process on outbound side, or the messages received from trading partner on inbound side.

• always Always eliminate duplicate messages. If this option is selected, the messages that are found to be duplicated will be eliminated, meaning they will not be sent out, or delivered to its destination. This applies to both inbound and outbound side.

• perMessage This only applies on outbound side. Once it's chosen, the dupElimination property in the messages sent from private process determines whether the message is to be eliminated if it's considered duplicated. This gives the user more flexibility for controlling this behavior on per message bases.

Receipt Tab

Require MSH Receipt

Require the MSH receipt for the action message. This applies on message receiving side to determine whether a receipt is to be created and replied to the message sending side.

On message sending side, the sending MSH will expect a receipt signal to be replied back if this is enabled, so the Reception Awareness feature is achieved. If the receipt is not received within a period of time, the original message could be resent.The options are:




The length of time to wait for an MSH receipt from the trading partner. After this time expires, the action message is resent to the trading partner as many times as specified in the Maximum Number of Retries field. After the last retry attempt, and another period of Time to Wait for MSH Receipt has passed, TIBCO BusinessConnect ebXML Protocol sends an error to the trading partner.


Field Description



Maximum Number of Retries

The number of times to retry sending the action message before receiving an MSH receipt.


Require the MSH receipt to be digitally signed and contains the digital digest of the received message. This applies on the message receiving side.

On message sending side, the replied receipt signal will be checked if it's signed properly, and the digital digest contained in the receipt will be matched with the preserved digest of the original message for data integrity.


Field Description



Exporting Transactions

You can export all the ebMS3 transaction configurations in the Operations Editor panel. You can also export a subset of the transactions: by individual transaction (Export Transaction), by version container (Export Version), by business process container (Export Business Process), or by organization container (Export Organization).

Follow the instructions below to export ebMS3 transactions:


2. To export all ebMS3 transactions in the Operations Editor panel:

a. Select the ebMS3 radio button.

b. Click Export.

c. Click Export Data.

Alternatively, to export a subset of the ebMS3 transactions:

d. Select the radio button next to the organization, business process, version, or transaction you wish to export.

e. Click Export Organization, Export Business Process, Export Version, or Export Transaction, depending on what you selected in the previous step.

You can now see the File Download dialog with operations.csx as the suggested filename.

3. Click Save in the File Download dialog.

4. Change to a desired filename and click Save.


Importing Transactions | 51

Importing Transactions

Follow the instructions below to import ebMS3 transactions in the Operations Editor:


2. Click Import in the right panel.

3. Click the Change... link.

4. Click Browse.

5. Locate the exported .csx file and click Open.

6. Click OK.

7. Click Import.

8. Click Done.


| 53

Chapter 5 Setting Up Trading Hosts

This chapter explains how to set up trading hosts in TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 Standard.

Topics

• Configuring ebMS3/AS4 Standard for Trading Hosts, page 54


54 | Chapter 5 Setting Up Trading Hosts

Configuring ebMS3/AS4 Standard for Trading Hosts

This section explains how to configure the ebMS3/AS4 Standard for a trading host in the BusinessConnect console in TIBCO Administrator. It assumes that you have already set up a host participant in the Participants panel. See TIBCO BusinessConnect Trading Partner Administration for detailed information on setting up a trading host.

Follow the instructions below to configure the ebXML protocol for a trading host:

1. In TIBCO Administrator, expand BusinessConnect > Participants in the left panel.

2. Click the name of a host participant in the right panel.

3. Click the Protocols tab.

4. Click the ebMS3 link.

5. Configure the properties in the General tab. See Table 10 for a description of each property.

6. Click Save twice.

Table 10 Trading Host General Properties

Field Description

Default Domain Identity The default domain identity to use for this host. Select from the list of domain-identity pairs you created in the Domain Identities dialog. See Adding Domain Identities on page 55 to add or edit a domain identity. This domain and identity will be present in the eb:PartyInfo/eb:From/eb:PartyId element on outbound message sent to trading partners, or should be in the eb:PartyInfo/eb:To/eb:PartyId element in inbound message received from trading partners.

Valid Email Address List Currently not used.

Queued Conversation Expiration Period (days)

The number of days a sequenced conversation is kept in the system before it is deleted. To keep sequenced conversations indefinitely, type 0 or a negative number (for example, -1) in this field. Currently this feature is not implemented.


Configuring ebMS3/AS4 Standard for Trading Hosts | 55

Adding Domain Identities

You must configure at least one domain-identity pair for your host participant. The domain value in the domain-identity pair corresponds to the type attribute of the public message’s PartyId element, and the identity value corresponds to the PartyId element itself.

Follow the instructions below to add a domain-identity pair for the ebXML protocol:

1. Click the Add New link to the right of the Default Domain Identity drop-down list.

2. Click the Add New button.

3. Select a domain from the Domain drop-down list. This is mapped to the domain string in the host’s domain-identity pair. If the domain you wish to use does not exist, see Domains on page 31 for instructions on adding domains.

4. Type the identity of the host participant in the Identity field.

5. Click Save.

If the domain you specify is URI, then you must specify a valid URI in the Identity field (for example, urn:123456789). However, the domain "URI" normally doesn't have to be present in outbound or inbound messages, as this is the "default" party id type for ebMS3 standard. For instance, if "URI" is used as the domain type of the trading partner, in outbound messages sent to trading partners, the domain "URI" will not present as the eb:PartyInfo/eb:To/eb:PartyId/@type attribute; similarly, in an inbound message if the eb:PartyInfo/eb:From/ebPartyId/@type attribute is absent, the "URI" will be considered the domain type.


56 | Chapter 5 Setting Up Trading Hosts


| 57

Chapter 6 Setting Up Trading Partners

This chapter explains how to set up trading partners in TIBCO BusinessConnect ebXML Protocol.

Topics

• Configuring ebMS3/AS4 Standard for Trading Partners, page 58

• General Tab, page 59

• Transports Tab, page 60


58 | Chapter 6 Setting Up Trading Partners

Configuring ebMS3/AS4 Standard for Trading Partners

This section explains how to configure the ebMS3/AS4 Standard protocol for a trading partner in TIBCO BusinessConnect. It assumes that you have already set up a partner participant in the Participants panel. See TIBCO BusinessConnect Trading Partner Administration for detailed information on setting up a trading partner.

Follow the instructions below to configure the ebMS3/AS4 Standard for a trading partner:

1. In TIBCO Administrator, expand BusinessConnect > Participants in the left panel.

2. Click the name of a partner participant in the right panel.


4. If ebMS3 does not appear in the list of protocols:

a. Click Enable.

b. Select the ebMS3 checkbox.

c. Click OK.


6. Configure each of the following tabs in the Edit Enabled Protocol: ebMS3 panel:

— General Tab See General Tab on page 59 for detailed information on configuring this tab.

— Transports Tab See Transports Tab on page 60 for detailed information on configuring transports.



Configuring ebMS3/AS4 Standard for Trading Partners | 59

General Tab

Use the General tab to manage general information for the ebMS3 trading partner.

Adding Domain Identities

You must configure at least one domain-identity pair for your partner participant. The domain value in the domain-identity pair corresponds to the type attribute of the public message’s PartyId element, and the identity value corresponds to the PartyId element itself.

Follow the instructions below to add a domain-identity pair for the ebXML protocol:

1. Click the Add New link to the right of the Default Domain Identity drop-down list.

2. Click the Add New button.

3. Select a domain from the Domain drop-down list. This is mapped to the domain string in the partner’s domain-identity pair. If the domain you wish to

Table 11 Trading Partner General Properties

Field Description

Default Domain Identity The default domain identity to use for this partner. Select from the list of domain identities created in the Domain Identity dialog. See Adding Domain Identities on page 59 to add or edit a domain identity. This domain and identity will be present in the eb:PartyInfo/eb:To/eb:PartyId element on outbound message sent to trading partners, or should be in the eb:PartyInfo/eb:From/eb:PartyId element in inbound message received from trading partners.

Valid Email Address List Currently not used.

AgreementRef The reference of the agreement between the host and this particular trading partner. Such an agreement is the set of P-Mode operations that are essential for two parties in order for their MSHs to interoperate. This reference will be present in the eb:CollobrationInfo/eb:AgreementRef element. In inbound messages sent from this trading partner, the eb:AgreementRef must have the same value in order to be accepted and processed.

Type The type of the AgreementRef value. If it is empty, then the AgreementRef value must be a valid URI.


60 | Chapter 6 Setting Up Trading Partners

use does not exist, see Domains on page 31 for instructions on adding domains.

4. Type the identity of the partner participant in the Identity field.

5. Click Save.

Transports Tab

Use the Transports tab to configure outbound transport settings for sending ebXML messages to this trading partner. To add an outbound transport, click Add in the Transports tab. The following transports can be used with TIBCO BusinessConnect ebXML Protocol:

• HTTPS (including HTTPSCA)

• HTTP

The steps required for configuring transports are the same for all protocols. See the transports chapters in TIBCO BusinessConnect Trading Partner Administration for detailed instructions.

If the domain you specify is URI, then you must specify a valid URI in the Identity field (for example, urn:123456789). However, the domain "URI" normally doesn't have to be present in outbound or inbound messages, as this is the "default" party id type for ebMS3 standard. For instance, if "URI" is used as the domain type of the trading partner, in outbound messages sent to trading partners, the domain "URI" will not present as the eb:PartyInfo/eb:To/eb:PartyId/@type attribute; similarly, in an inbound message if the eb:PartyInfo/eb:From/ebPartyId/@type attribute is absent, the "URI" will be considered the domain type.


| 61

Chapter 7 Configuring Agreement Protocol Bindings

This chapter describes setting up business agreements to use TIBCO BusinessConnect ebXML Protocol.

In above we discussed how to configure the operation definitions, the host and the trading partners. However the trading partner and the host must have an agreement on which operations to be supported for the interactions between them, which role each of the party should play in each of the transactions, the transport to be used for the interactions, etc. The operations can also be overridden with specific settings agreed on by the two parties. All these are configured in Business Agreement.

Inside the Business Agreement, the settings about ebMS3/AS4 are called ebMS3 Protocol Bindings.

Topics

• Configuring Business Agreements with ebMS3 Protocol ebMS3/AS4 Standard, page 62

• Configuring Operation Bindings, page 63

• Setting Document Security Properties, page 66

• Configuring Transports, page 68

• Overriding Participant Settings, page 70


62 | Chapter 7 Configuring Agreement Protocol Bindings

Configuring Business Agreements with ebMS3 Protocol ebMS3/AS4

Standard

Follow the instructions below to configure a business agreement with the ebMS3 protocol binding:

1. In TIBCO Administrator, expand BusinessConnect > Business Agreements in the left panel.

2. Click a business agreement link in the right panel.

3. Click the Add Protocol Bindings button.

4. Select ebMS3.

5. Click OK.

6. Click the ebMS3 link to open the Edit Protocol Bindings: ebMS3 panel.

7. Configure each of the following tabs:

— Operation Bindings See Configuring Operation Bindings on page 63.

— Document Security Setting Document Security Properties on page 66.

— Transports See Configuring Transports on page 68.

— Participant Configurations (Override) See Overriding Participant Settings on page 70.



Configuring Operation Bindings | 63

Configuring Operation Bindings

Use the Operation Bindings tab to configure the ebMS3 transactions that each party in a business agreement can initiate and respond to. The following properties apply to all transactions in the Operations Editor:

• Allow All Operations Allow all transactions configured in the Operations Editor between participants. If you select this option, you can still modify the behavior of one or more transactions by binding the transactions in the Host ’X’ Can Initiate and Partner ’Y’ Can Initiate areas.

If you do not select this option, you must explicitly bind each transaction for each party in the Host ’X’ Can Initiate and Partner ’Y’ Can Initiate areas.

• Non Repudiation Logging Log transactions in the non-repudiation log, including all action messages and signal messages.

Binding Operations

The Host ’X’ Can Initiate area (where X is the host participant in the business agreement) lists the operations that the host is allowed to initiate in this agreement. The Partner ’Y’ Can Initiate area (where Y is the partner participant in the business agreement) lists the operations that the partner is allowed to initiate.

Follow the instructions below to bind operations in either area:

1. Click Add Operation Binding.

2. Click the icons to expand the browser tree.

3. Select the ebMS3 transactions you wish to bind.

4. Click OK.

Editing Operation Bindings

Follow the instructions below to edit an ebMS3 operation binding:

1. Click the name of an operation in the Host ’X’ Can Initiate area or Partner ’Y’ Can Initiate area.



2. Configure this particular operation binding in the following tabs:

— Operation Settings Override the default settings for this transaction. See Operation Settings Tab on page 64.

— Action Settings Override settings chosen in Action Settings Tab on page 65.

— Transports Override the default transport settings for this transaction. See Transports Tab on page 65.

3. Click Save.

Operation Settings Tab

You can override the default operation settings in the Operations Editor panel. See Adding Transactions on page 36 for information on configuring a transaction’s default settings in the Operations Editor.

Follow the instructions below to override the default operation settings:

1. Select the Override Operation Settings checkbox at the top.

2. Select one of the following items from the drop-down list to override operation settings for this transaction:

— Roles Selecting this item allows you to override the fields in the Roles sub-tab for this transaction in the Operations Editor panel. See the Roles section in Table 3 on page 36 for a description of each field.

— Service Information Selecting this item allows you to override the P-Mode ID field in the Service Information sub-tab for this transaction in the Operations Editor panel. The P-Mode ID you provide here identifies the specific settings in this operation binding, and overrides the default P-Mode ID configured for this transaction in operation editor. The service and type values cannot be overridden. See the Service Information section in Table 3 on page 36 for a description of the P-Mode ID field.

— Document Selecting this item allows you to override the fields in the Document sub-tab for this transaction in the Operations Editor panel. See the Document section in Table 3 on page 36 for a description of each field.


Configuring Operation Bindings | 65

Action Settings Tab

You can also override the default settings of a specific action. A transaction’s default action settings can be found in the Operations Editor.

Follow the instructions below to override action settings:

1. Click the Action Settings tab.

2. Select the Override Action Settings checkbox.

3. Select one of the following items from the drop-down list to override operation settings for this transaction:

— General Selecting this item allows you to override the fields in the General sub-tab for this action in the Operations Editor panel.

— Receipt Selecting this item allows you to override the fields in the Receipt sub-tab for this action in the Operations Editor panel.

Transports Tab

After you define transport settings for a business agreement (see Configuring Transports on page 68), you can override the transport settings for a specific transaction. Follow the instructions below to override outbound transport settings:

1. Click the Transports tab.

2. Select the Override Transports checkbox.

3. Select the transport you wish to use in the Primary Transport drop-down list.

Operations you select in the Host ’X’ Can Initiate area can only have their Request Action tab settings overridden, while operations you select in the Partner ’Y’ Can Initiate area can only have their Response Action tab settings overridden.



Setting Document Security Properties

You can use the Document Security tab to specify security information for the transacted ebXML documents between the participants in this business agreement. The keys and certificates selected in the tab are configured in a participant’s Credentials tab. See TIBCO BusinessConnect Trading Partner Administration for information on configuring participant credentials.

Follow the instructions in Configuring Business Agreements with ebMS3 Protocol ebMS3/AS4 Standard on page 62 to get to the Document Security tab. Then, consult Table 12 to configure the document security properties.

Table 12 Document Security Properties

Field Description

Outbound Doc Exchange

Signing Key The private key of the selected host. TIBCO BusinessConnect ebXML Protocol uses this key to sign outbound documents in this business agreement.

You must have already installed a private key for this host during participant configuration. See TIBCO BusinessConnect Trading Partner Administration for more information on installing private keys for host participants.

Digest Algorithm This drop-down list has multiple digest algorithm options, among them either SHA-1 or SHA-256 can be chosen for the digest algorithm used by the digital signature of ebMS3/AS4 Standard.

Encryption Certificate The public certificate of the selected partner. TIBCO BusinessConnect ebXML Protocol uses this certificate to encrypt outbound messages in this business agreement.

You must have already installed a certificate for this partner during participant configuration. See TIBCO BusinessConnect Trading Partner Administration for more information on installing certificates for partner participants.

Encryption Algorithm The algorithm used to encrypt documents.The available options are DES3, RC2-40, RC2-128, AES-128, AES-192, AES-256 among which the RC2-40 and RC2-128 are not supported for encryption of ebMS3/AS4 standard.


Setting Document Security Properties | 67

Inbound Doc Exchange

Verification Certificate The public key of the selected partner. TIBCO BusinessConnect ebXML Protocol uses this key to verify the signed inbound documents in this business agreement.

You must have already installed a certificate for this partner during participant configuration. See TIBCO BusinessConnect Trading Partner Administration for more information on installing certificates for partner participants.

Decryption Key The private key of the selected host. TIBCO BusinessConnect ebXML Protocol uses this key to decrypt inbound messages in this business agreement.

You must have already installed a private key for this host during participant configuration. See TIBCO BusinessConnect Trading Partner Administration for more information on installing private keys for host participants.

Table 12 Document Security Properties (Cont’d)

Field Description



Configuring Transports

As part of the ebXML protocol binding in a business agreement, you must specify which transports to allow for the host and the partner.

Follow the instructions in Configuring Business Agreements with ebMS3 Protocol ebMS3/AS4 Standard on page 62 to get to the Transports tab, and read this section for more information on how to configure in this tab.

Outbound Transports for Host

This area of the Transports tab allows you to assign a transport for sending business transaction messages to this trading partner. The transport methods themselves are configured as a part of the partner configuration:

Participants > Name > Protocols > ebMS3 > Transports.

Detailed information about configuring transports is available in the TIBCO BusinessConnect Trading Partner Administration.

Table 13 lists and describes the options available for transport assignment with ebMS3.

Allowed Inbound Transports for Partner

This area of the Transports tab allows you to specify which transport types your partner can use to send ebMS3 messages to your BusinessConnect implementation. The transport types available for selection here reflect the transports configured for this BusinessConnect deployment. Transports for the deployment are configured in the BusinessConnect console of TIBCO Administrator:

BusinessConnect > System Settings > Inbound Public Transport Types

Table 13 Outbound Transports for Host

Field Description

Primary Transport The transport to choose for sending outbound messages among the multiple outbound transports you might have defined for this trading partner.

Client Authentication Identity for HTTPS, FTPS, HTTPSCA

The key identity used when the remote server requires client authentication for an HTTPS connection.


Configuring Transports | 69

The TIBCO BusinessConnect Trading Partner Administration provides detailed information on configuring transports in the Inbound Public Transport Types tab.

Depending on your deployment configuration, the following transports can be available for selection:

Overriding Outbound Transport Settings

The outbound transaction chosen above is the default transport of this Business Agreement. However, you can override this with another transport for a particular operation.

Follow the instructions below to override the outbound transport settings:

1. In the Edit Protocol Bindings: ebMS3 panel, click the Operation Bindings tab.

2. Click an operation in the Host ’X’ Can Initiate or Partner ’Y’ Can Initiate area.

3. Continue by following the instructions in Transports Tab on page 65.

Table 14 Inbound Transport Fields

Field Description

HTTPSCA Allow Client Authentication when you select HTTPS as the allowed inbound transport (see below).

HTTPS Allow HTTPS connections from this partner directly.

HTTP Allow HTTP connections from this partner directly.



Overriding Participant Settings

There are two additional hidden tabs in the Edit Protocol Bindings: ebMS3 panel that enable you to override each participant’s general protocol settings, which are configured in the General tab of the participant’s ebMS3 protocol configuration panel. See Configuring ebMS3/AS4 Standard for Trading Hosts on page 54 and Configuring ebMS3/AS4 Standard for Trading Partners on page 58 for information on configuring these default settings.

Follow the instructions below to override the participant settings for a business agreement:

1. Follow the instructions in Configuring Business Agreements with ebMS3 Protocol ebMS3/AS4 Standard on page 62 to get to the Edit Protocol Bindings: ebMS3 panel.

2. Click the Show Advanced button in the upper-right corner.

You will see two configuration tabs, one for each participant in this business agreement.

3. Click the configuration tab for the desired participant.

4. Select the Override Settings checkbox.

5. Configure the settings in this tab. See Table 10 on page 54 (for a host) or Table 11 on page 59 (for a partner) for a description of each parameter.



| 71

Chapter 8 Private Processes

This chapter describes the interaction between TIBCO BusinessConnect ebXML Protocol and its private processes and gives specifications for private process messages.

Topics

• Configuring Private Processes, page 72

• Private Process Message Formats, page 73

• Configuring Private Processes with TIBCO ActiveMatrix BusinessWorks, page 99


72 | Chapter 8 Private Processes

Configuring Private Processes

TIBCO BusinessConnect Private Processes are enterprise back-office system or connections to the back-office system. They can be implemented by technology or any language, with the only requirement that they use TIBCO Rendezvous or JMS transport to communicate with TIBCO BusinessConnect Interior Servers with certain format. They can also leverage TIBCO ActiveMatrix BusinessWorks to implement the private processes.

• Standalone Standalone private processes are implemented by any technology or language which directly use Rendezvous or JMS to communicate with BusinessConnect.

• TIBCO ActiveMatrix BusinessWorks You can also use TIBCO ActiveMatrix BusinessWorks to implement the private processes, which leverage BusinessConnect Palette that work inside BusinessWorks to communicate with BusinessConnect. You can also use TIBCO Designer to test your private processed in debug mode.

Standalone Private Processes

If you wish to design standalone private processes for use with TIBCO BusinessConnect ebXML Protocol, you must understand Rendezvous or JMS message exchange. TIBCO BusinessConnect ebXML Protocol uses TIBCO ActiveExchange™ messages to exchange ebMS3 messages with private processes. See Private Process Message Formats on page 73 for formatting information of ebMS3 messages.

TIBCO ActiveMatrix BusinessWorks Processes

The BusinessConnect palette, which is installed into TIBCO ActiveMatrix BusinessWorks during the BusinessConnect Service Plug-in installation, encapsulates the message exchange configurations. The variety of TIBCO ActiveMatrix BusinessWorks palettes also enables you to define elaborate private processes to suit the needs of your business transactions.

See Configuring Private Processes with TIBCO ActiveMatrix BusinessWorks on page 99 for more information on using TIBCO ActiveMatrix BusinessWorks private processes.

Also, see Chapter 10, Tutorial, on page 113 for a tutorial on configuring TIBCO ActiveMatrix BusinessWorks private processes to send and receive messages with TIBCO BusinessConnect ebXML Protocol.


Private Process Message Formats | 73

Private Process Message Formats

TIBCO BusinessConnect ebXML Protocol uses ActiveExchange™ messages to exchange ebMS3 messages with private processes via Rendezvous or JMS. This section describes the ebXML-specific data classes that are used in the messages. You must format messages and include all required information as prescribed by the respective data classes before they are sent from private processes. By using TIBCO ActiveMatrix BusinessWorks and leveraging BusinessConnect Palettes which work with BusinessWorks, the message formatting is automatic.

For Rendezvous transport, TIBCO BusinessConnect ebXML Protocol uses aeRvMsg messages to communicate with private processes, transmitting message data in the ^data^ control tag of the aeRvMsg messages. For JMS transport, it transmits message data in the message body of JMS ObjectMessage messages. See the Private Processes section in TIBCO BusinessConnect Concepts for more information.

Go to one of the sections below for formatting details of the respective ebMS3 message type:

• Outbound Request Format, page 74

• Request Acknowledgment Format, page 79

• Inbound Response Format, page 81

• Inbound Request Format, page 84

• Outbound Response Format, page 87

• Response Acknowledgment Format, page 90

• Advisory Signal Message Format, page 92

• Error Message Format, page 95

Data Types and Data Fields

See the following sections for formats of specific message fields and other data objects:

• Additional Data Classes, page 97

The JMS topics and queues that TIBCO BusinessConnect ebXML Protocol uses do not contain the protocol name. You must make sure that the JMSType attribute in the header element contains the string "ebMS3" when exchanging JMS messages with TIBCO BusinessConnect ebXML Protocol.



Outbound Request Format

The initiator private process uses the following message class to send outbound request messages to TIBCO BusinessConnect ebXML Protocol.

Class ae/ebMS3/InitiatorRequest

Subject name prefix.installation.ebMS3.INITIATOR.REQUEST (Rendezvous)

Example: AX.BC.ACME_SERVER.ebMS3.INITIATOR.REQUEST

prefix.installation.INITIATOR.REQUEST (JMS queue)

Message fields See Table 15 for description of each message field.

BC

Initiator

BC

Responder

Initiator Request

InternetInitiator

Private

Process

Responder

Private

Process

Table 15 ae/ebMS3/InitiatorRequest Message Fields (Sheet 1 of 6)

Field Type Required Description

standardID String Yes The string "ebMS3".



hostDomain String No The trading host’s domain name, which is actually the PartyID Type of the host in ebMS3 transactions. TIBCO BusinessConnect ebXML Protocol uses the hostDomain field and the hostID field as follows:

• If hostDomain and hostID together match a domain-identity pair of a trading host, then that host is used along with the matching domain-identity pair.

• If only hostDomain is specified, then the first domain-identity pair of any trading host that has a matching domain value is used.

• If neither hostDomain and hostID are specified, or if a match cannot be found for any host in the configuration store, then the default domain identity of the default trading host is used.

hostID String No The identity value of the trading host’s domain-identity pair, which is actually the PartyID of the host in ebMS3 transactions. See the description for hostDomain on how this field is used.

tpName String Yes The name of the trading partner in this transaction, as defined in the Participants panel in the BusinessConnect console.

tpDomain String No The trading partner’s domain name, which is actually the PartyID Type of the trading partner in ebMS3 transactions. Specify a domain here if you wish to use a domain identity other than the one configured in the Default Domain Identity field of the trading partner’s Participants panel.





operationID String No The identifier for the transaction defined in ebMS3 operation definitions in the configuration store. For example: rosettanet.org/3A4/2.0/Request Purchase

Order.

This field is ignored when there are values in all of the following fields:

• organization

• businessProcess

• businessProcessVersion

• transactionName.

organization String No The organization name for the transaction. For example: rosettanet.org.

When there is a value in this field, there must be a value in the businessProcess, businessProcessVersion, and transactionName field. When this combination does not exist, the operationID field is used.

businessProcess String No The name of the business process as defined by the organization you use. For example: 3A4.

When there is a value in this field, there must be a value in the organization, businessProcessVersion, and transactionName field. When this combination does not exist, the operationID field is used.

businessProcess

VersionString No The business process version. For example: 2.0.

When there is a value in this field, there must be a value in the organization, businessProcess, and transactionName field. When this combination does not exist, the operationID field is used.





transactionName String No The name of the transaction. For example: Request Purchage Order.

When there is a value in this field, there must be a value in the organization, businessProcess, and businessProcessVersion field. When this combination does not exist, the operationID field is used.

request String Yes The request payload, which is usually an XML string. In the ebMS3 outbound request message, this will be the content of the SOAP body.

Note: Text-based payloads and attachments must be encoded in UTF-8. In BusinessConnect Palette, the body field is used to specify the content of the request field. Also this field is ignored when the requestFile field is not empty.

requestFile String No The file reference of the payload content. This can be used to send large payload.

Note: This field takes precedence over the request field.

PayloadInfo N/A No Information of the payload of the request message. This is the payload to be sent in the SOAP body.

See PayloadInfo on page 165 for more information about the sub-fields.

attachment Sequence of ebMS3/Info/

Attachment

No A sequence of attachments. Each of the attachments will be sent out in one of the SOAP Attachments in the public message.

See Table 23 on page 97 for formatting information.

conversationID String No A unique identifier unique to this conversation. If you do not supply a value here, it is automatically generated for the public message.





messageID String No A unique identifier for the outbound ebMS3 message. It must conform to the format described in RFC 2822. Otherwise, your trading partner may not be able to process the message properly.

If you do not supply a value here, it is automatically generated by BusinessConnect Server for the public message.

toBePulled Boolean No Set this field to be true only when the message is not intended to be sent out directly, but rather be stored in Store-and-Forward, to be pulled by the trading partner.

mpc String No The URI that identifies the message partitioning channel to which the message is assigned. This can be present to both a Push message and a message to be pulled.

authorizationTo

kenN/A No Include username and password information

that is used for Pull Request authorization. For a Pull Request message, both the user name and password need to be specified. For a message to be stored in Store-and-Forward, only the user name needs to be specified. For a message to be pushed out directly, this is not a required field.

authenticationT

okenN/A No Include username and password information

that is used for WSS UsernameToken authentication, which is an alternative other than the WSS signature authentication. This can be used for all types of messages.

dupElimination Boolean No Request that the duplicate messages sent by the private process will be eliminated by the BusinessConnect outbound process.





Request Acknowledgment Format

TIBCO BusinessConnect ebXML Protocol uses the following message class to indicate to the private process whether the request is sent to the trading partner successfully.

Class ae/ebMS3/InitiatorAck

Subject prefix.installation.ebMS3.INITIATOR.ACK (Rendezvous)

Example: AX.BC.ACME_SERVER.ebMS3.INITIATOR.ACK

prefix.installation.INITIATOR.ACK (JMS queue)

closure String No A unique string for TIBCO BusinessConnect ebXML Protocol to keep track of this transaction. It is copied to all response messages of this request.

If you do not supply a value here, it is automatically generated by TIBCO BusinessConnect ebXML Protocol.

trackingID String No An identifier that allows the private process to keep track of messages that are otherwise related to each other. It is copied to all response messages to this request.

Contrary to the closure and conversationID fields, there is no requirement on the value of this field, nor is it used to process public messages.



BC

Initiator

BC

Responder

InternetInitiator

Private

Process

Responder

Private

Process

Initiator Ack




Table 16 ae/ebMS3/InitiatorAck Message Fields



tpName String Yes The name of the trading partner, as specified in the tpName field in the corresponding ae/ebMS3/InitiatorRequest message.

tradingPartner TradingPartner

Yes The trading partner. See Table 24 on page 98 for formatting information.

host TradingPartner

Yes The trading host. See Table 24 on page 98 for formatting information.

operationID String Yes The identifier of the transaction. For example: rosettanet.org/3A4/2.0/Request Purchase

Order.

organization String Yes The organization name for the transaction.

businessProcess String Yes The name of the business process for the transaction.

businessProcess

VersionString Yes The business process version for the transaction.

transactionName String Yes The name of the transaction.

agreementRef String No The value of the AgreementRef element in the public message’s ebMS3 Messaging header. This is configured in the AgreementRef field of the Participants panel for the trading partner. See Chapter 6, Setting Up Trading Partners, on page 57 for more information.

conversationID String Yes The value of the ConversationId element in the public message’s ebMS3 messaging header.

messageID String Yes The value of the MessageData/MessageId element in the public message’s ebMS3 messaging header.



Inbound Response Format

TIBCO BusinessConnect ebXML Protocol uses the following message class to forward inbound response messages to the initiator private process.This is in the scenario of a two-way transaction, where the response is replied by the responder in the second leg of the two-way transaction.

Class ae/ebMS3/InitiatorResponse

Subject prefix.installation.ebMS3.INITIATOR.RESPONSE (Rendezvous)

Example: AX.BC.ACME_SERVER.ebMS3.INITIATOR.RESPONSE

prefix.installation.INITIATOR.RESPONSE (JMS queue)


closure String No A unique string for TIBCO BusinessConnect ebXML Protocol to keep track of this transaction. It is either generated by TIBCO BusinessConnect ebXML Protocol or copied from the closure field in the corresponding ae/ebMS3/InitiatorRequest message.

trackingID String No The value of the trackingID field in the corresponding ae/ebMS3/InitiatorRequest message, which can be used by the private process to keep track of messages that are otherwise related to each other.

Table 16 ae/ebMS3/InitiatorAck Message Fields (Cont’d)


BC

Initiator

BC

Responder

Initiator Response

InternetInitiator

Private

Process

Responder

Private

Process



Table 17 ae/ebMS3/InitiatorResponse Message Fields (Sheet 1 of 3)



fromTP TradingPartner


host TradingPartner


fromRole String No The value of the From/Role element in the ebMS3 messaging header of the inbound public message.

toRole String No The value of the To/Role element in the ebMS3 messaging header of the inbound public message.

operationID String Yes The identifier of the transaction as defined in operation definition in local configuration. For example: rosettanet.org/3A4/2.0/Request Purchase Order.



businessProcess

VersionString Yes The business process version for the

transaction.


statusCode Integer Yes A code indicating the status of the transaction. See Appendix A, Status Codes, on page 141 for more information.

statusMsg String Yes A brief description of the code in the statusCode field.

mpc String No The URI that identifies the message partitioning channel to which the message is assigned.



timestamp String No The timestamp when the ebMS3 message is generated.

response String No The response payload, which is usually an XML string. The content of this field comes from the content of the SOAP body in the inbound response ebMS3 message.

Note: In BusinessWorks Palette, the body field is used to specify the content of the response field. Also the field is ignored when the responseFile is not empty.

responseFile String No The file reference when the size of the payload exceeds the private process file size threshold.

You can configure this using the ebxml.fileref.threshold property from System Settings > Activated Protocol Plug-ins and Properties > ebXML.

Note: This field takes precedence over the response field.

PayloadInfo N/A No Information of the payload of the response message. This is the payload encapsulated as the content of the SOAP Body.



Attachment

No A sequence of attachments which are sent from trading partner as the SOAP Attachments.


agreementRef String No The value of the AgreementRef element in the ebMS3 messaging header of the inbound public message.

conversationID String Yes The value of the ConversationId element in the ebMS3 messaging header of the inbound public message.





Inbound Request Format

TIBCO BusinessConnect ebXML Protocol uses the following message class to forward inbound request messages to the responder private process.

Class ae/ebMS3/ResponderRequest

Subject prefix.installation.ebMS3.RESPONDER.REQUEST (Rendezvous)

Example: AX.BC.ACME_SERVER.ebMS3.RESPONDER.REQUEST

prefix.installation.RESPONDER.REQUEST (JMS queue)

messageID String Yes The value of the MessageData/MessageId element in the ebMS3 messaging header of the inbound public message.

closure String No A unique string for TIBCO BusinessConnect ebXML Protocol to keep track of this transaction. It is either generated by TIBCO BusinessConnect ebXML Protocol or copied from the closure field in the corresponding ae/ebMS3/InitiatorRequest message.

trackingID String No The value of the trackingID field in the corresponding ae/ebMS3/InitiatorRequest message, which can be used by the private process to keep track of messages that are otherwise related to each other.



BC

Initiator

BC

Responder

Responder

Request

InternetInitiator

Private

Process

Responder

Private

Process




Table 18 ae/ebMS3/ResponderRequest Message Fields



fromTP TradingPartner

No The trading partner. See Table 24 on page 98 for formatting information.

host TradingPartner


fromRole String No The role of the trading partner, which is copied from the From/Role element in the SOAP header of the inbound public message.

toRole String No The role of the trading host, which is copied from the To/Role element in the SOAP header of the inbound public message.

operationID String Yes The identifier of the transaction. For example: rosettanet.org/3A4/2.0/Request

Purchase Order.



businessProcess

VersionString Yes The business process version for the

transaction.


service String Yes The service that acts on the message, which is copied from the Service element in the SOAP header of the inbound public message.

serviceType String No The service type, which is copied from the Service/@type attribute in the SOAP header of the inbound public message.

action String Yes The action name in the inbound message, which is copied from the Action element in the SOAP header of the inbound public message.



mpc String No The message partitioning channel to which the message is assigned.

timestamp String No The timestamp when the ebMS3 message is generated.

request String No The request payload, which is usually an XML string. The content of this field comes from the SOAP body content of the inbound ebMS3 message.

Note: In BusinessWorks Palette, the body field is used to specify the content of the request field. Also this field is ignored when the requestFile field is not empty.

requestFile String No The file reference when the size of the payload exceeds the private process file size threshold.

You can configure this using the ebxml.fileref.threshold property from System Settings > Activated Protocol Plug-ins and Properties > ebXML.

Note: This field takes precedence over the request field.

PayloadInfo N/A No Information of the payload of the request message. This is the payload encapsulated as the content of the SOAP Body.



Attachment

No A sequence of attachments received from the trading partner as the SOAP Attachments.


agreementRef String No The identifier of the collaboration protocol agreement, copied from the AgreementRef element in the ebMS3 messaging header of the inbound public message.

Table 18 ae/ebMS3/ResponderRequest Message Fields (Cont’d)




Outbound Response Format

The responder private process uses the following message class to send outbound response messages and business-level exceptions to TIBCO BusinessConnect ebXML Protocol.

Class ae/ebMS3/ResponderResponse

Subject name prefix.installation.ebMS3.RESPONDER.RESPONSE (Rendezvous)

Example: AX.BC.ACME_SERVER.ebMS3.RESPONDER.RESPONSE

prefix.installation.RESPONDER.RESPONSE (JMS queue)

conversationID String Yes The identifier for the current conversation, copied from the ConversationId element in the SOAP header of the inbound public message.

messageID String Yes The unique identifier for the inbound, request, copied from the MessageData/MessageId element in the SOAP header of the inbound public message.

closure String Yes A unique string generated by TIBCO BusinessConnect ebXML Protocol to keep track of this transaction. You must copy the value here to the closure field in the corresponding ae/ebMS3/ResponderResponse message.

Table 18 ae/ebMS3/ResponderRequest Message Fields (Cont’d)


BC

Initiator

BC

Responder

Responder

Response

InternetInitiator

Private

Process

Responder

Private

Process




Table 19 ae/ebMS3/ResponderResponse Message Fields



statusCode Integer Yes The status of this transaction. Specify one of the following codes:

• 200 The request is processed successfully.

• 3652 The request is processed successfully but rejected. In this case, TIBCO BusinessConnect ebXML Protocol sends a response message to the trading partner with AcceptanceException as the value of the ExceptionType element.

• 3650 The request is not processed successfully. In this case, TIBCO BusinessConnect ebXML Protocol sends a response message to the trading partner with GeneralException as the value of the ExceptionType element.

statusMsg String Yes A description of the code in the statusCode field. See Appendix A, Status Codes, on page 141 for more information.

response String No The response payload, which is usually an XML string. This is the payload to be encapsulated in the SOAP Body in the public response message.

Note: Text-based payloads and attachments must be encoded in UTF-8. In BusinessWorks Palette, the body field is used to specify the content of the response field. Also the field is ignored when the responseFile is not empty.

responseFile String No The file reference used to specify the response payload file. Customer can use the file reference to send large payload.

Note: This field takes precedence over the response field.



PayloadInfo N/A No Information of the payload of the response message, which is the content of the SOAP Body of the response message.



Attachment

No A sequence of attachments to be sent out as SOAP Attachments in the public response message.


messageID String No A unique identifier for the outbound ebMS3 message. It must conform to the format described in RFC 2822. Otherwise, your trading partner may not be able to process the message properly.

If you do not supply a value here, it is automatically generated for the public message.

closure String No A unique string for TIBCO BusinessConnect ebXML Protocol to keep track of this transaction. You must copy the value from the closure field in the corresponding ae/ebMS3/ResponderRequest message.

authorizationT

okenN/A No Not used for Responder.Response messages.

authentication

TokenN/A No Include username and password information that

is used for WSS UsernameToken authentication, which is an alternative other than the WSS signature authentication.

dupElimination Boolean No Request that the duplicate response messages sent by the private process will be eliminated by the BusinessConnect outbound process.

ackRequested Boolean No Not used for Responder.Response messages.

ackSignature

RequestedBoolean No Not used for Responder.Response messages.

Table 19 ae/ebMS3/ResponderResponse Message Fields (Cont’d)




Response Acknowledgment Format

TIBCO BusinessConnect ebXML Protocol uses the following message class to indicate to the private process whether the response message is sent to the trading partner successfully.

Class ae/ebMS3/ResponderAck

Subject prefix.installation.ebMS3.RESPONDER.ACK (Rendezvous)

Example: AX.BC.ACME_SERVER.ebMS3.RESPONDER.ACK

prefix.installation.RESPONDER.ACK (JMS queue)


trackingID String No An identifier that allows the private process to keep track of messages that are otherwise related to each other. It is copied to the corresponding ae/ebMS3/ResponderAck message.

Contrary to the closure and conversationID fields, there is no requirement on the value of this field, nor is it used to process public messages.

Table 19 ae/ebMS3/ResponderResponse Message Fields (Cont’d)


BC

Initiator

BC

Responder

InternetInitiator

Private

Process

Responder

Private

Process

Responder Ack

Table 20 ae/ebMS3/ResponderAck Message Fields







host TradingPartner


statusCode Integer Yes A code indicating the status of the transaction. See Appendix A, Status Codes, on page 185 for more information.

statusMsg String Yes A brief description of the code in the statusCode field.

operationType String No The identifier of the transaction. For example: rosettanet.org/3A4/2.0/Request Purchase

Order.

closure String Yes A unique string for TIBCO BusinessConnect ebXML Protocol to keep track of this transaction. It is copied from the closure field in the corresponding ae/ebMS3/ResponderRequest message.

operationID String Yes The identifier of the transaction. For example: rosettanet.org/3A4/2.0/Request Purchase

Order.



businessProcess

VersionString Yes The business process version for the transaction.



conversationID String Yes The value of the ConversationId element in the public message’s SOAP header.

Table 20 ae/ebMS3/ResponderAck Message Fields (Cont’d)




Advisory Signal Message Format

TIBCO BusinessConnect ebXML Protocol uses the ae/ebMS3/Advisory class to update private processes on the status of ebMS3 transactions. TIBCO BusinessConnect ebXML Protocol publishes ae/ebMS3/Advisory messages on the advisory signals subject when it receives signals from the trading partner.

See Processing Signals on page 14 for more information on signals.

The field names map to (but are not the same as) column names in the audit database, and their values match the values that are written to the audit database.

Class ae/ebMS3/Advisory

Subject prefix.installation.ebMS3.ADVISORY.SIGNALS (Rendezvous)

Example: AX.BC.ACME_SERVER.ebMS3.ADVISORY.SIGNALS

prefix.installation.ADVISORY.SIGNALS (JMS topic)


messageID String No The value of the MessageData/MessageId element in the public message’s SOAP header.

trackingID String No The value of the trackingID field in the corresponding ae/ebMS3/ResponderResponse message, which can be used by the private process to keep track of messages that are otherwise related to each other.

Table 20 ae/ebMS3/ResponderAck Message Fields (Cont’d)


The ae/ebMS3/Advisory message class is used for both advisory and error signals, but they are sent to separate private message subjects, and some of the message fields can hold different data for advisory and error signals.

Table 21 ae/ebMS3/Advisory Signal Fields





tpName String No The name of the trading partner in this transaction, as defined in the Participants panel in the BusinessConnect console.


Yes The trading partner. See Table 24 for formatting information.

host TradingPartner

Yes The trading host. See Table 24 for formatting information.

operationID String No The identifier of the transaction. For example: rosettanet.org/3A4/2.0/Request Purchase

Order.

transactionID String No Currently not used.

statusCode Integer No The status of this transaction. See below for possible codes:

• 1651 Received a receipt acknowledgment from the trading partner.

• 1653 Received an MSH receipt from the trading partner.

• 3650 Received an exception message from the trading partner with an ExceptionType/GeneralException element in the message payload, indicating that trading partner’s private process failed to process the request or response.

• 3652 Received an exception message from the trading partner with an ExceptionType/AcceptanceException element in the message payload, indicating that the trading partner’s private process rejected the request or response.

See Appendix A, Status Codes, on page 141 for more information.

statusMsg String No A brief description of the code in the statusCode field.

Table 21 ae/ebMS3/Advisory Signal Fields (Cont’d)




details String No A more detailed description of the transaction status. This can be an analysis of the error that occurred.

extraInfo String No The XML-formatted signal message that is received.

closure String No A unique string for TIBCO BusinessConnect ebXML Protocol to keep track of this transaction. It is copied from the closure field in the corresponding ae/ebMS3/InitiatorRequest or ae/ebMS3/ResponderRequest message.

organization String No The organization name for the transaction.

businessProcess String No The name of the business process for the transaction.

businessProcess

VersionString No The business process version for the transaction.

transactionName String No The name of the transaction.

service String No The service that actions on the message, which is copied from the Service element in the SOAP header of the public message.

serviceType String No The service type, which is copied from the Service/type attribute in the SOAP header of the public message.

action String No The action used to process the inbound message, which is copied from the Action element in the SOAP header of the public message. If the value of the Action element is Exception, then the value here is GeneralException or AcceptanceException, depending on the kind of exception.






Error Message Format

TIBCO BusinessConnect ebXML Protocol also uses the ae/ebMS3/Advisory class to send transaction errors to private processes.

The field names map to (but are not the same as) column names in the audit database, and their values match the values that are written to the audit database.

Class ae/ebMS3/Advisory

Subject prefix.installation.ebMS3.ERROR (Rendezvous)

Example: AX.BC.ACME_SERVER.ebMS3.ERROR

prefix.installation.ERROR (JMS topic)


conversationID String No The value of the ConversationId element in the public message’s SOAP header.


trackingID String No The value of the trackingID field in the corresponding ae/ebMS3/InitiatorRequest or ae/ebMS3/ResponderResponse message, which can be used by the private process to keep track of messages that are otherwise related to each other.



The ae/ebMS3/Advisory message class is used for both advisory and error signals, but they are sent to separate private message subjects, and some of the message fields can hold different data for advisory and error signals.

Table 22 ae/ebMS3/Advisory Error Fields



tpName String No The name of the trading partner in this transaction, as defined in the Participants panel in the BusinessConnect console.




Yes The trading partner. See Table 24 for formatting information.

host TradingPartner

Yes The trading host. See Table 24 for formatting information.

operationID String No The identifier of the transaction. For example: rosettanet.org/3A4/2.0/Request Purchase

Order.

statusCode Integer No A code indicating the status of the transaction. See Appendix A, Status Codes, on page 141 for more information.

statusMsg String No A brief description of the code in the statusCode field.

closure String No A unique string for TIBCO BusinessConnect ebXML Protocol to keep track of this transaction. It is copied from the closure field in the corresponding ae/ebMS3/InitiatorRequest or ae/ebMS3/ResponderRequest message.

organization String No The organization name for the transaction.

businessProcess String No The name of the business process for the transaction.

businessProcess

VersionString No The business process version for the transaction.

transactionName String No The name of the transaction.

service String No The service that actions on the message, which is copied from the Service element in the SOAP header of the public message.

conversationID String No The value of the ConversationId element in the public message’s SOAP header.


Table 22 ae/ebMS3/Advisory Error Fields (Cont’d)




Additional Data Classes

Two additional data classes are commonly used by some of the private process message classes:

• ae/BC/Attachment (see Table 23 for a description of each field)

• ae/BC/TradingPartner (See Table 24 for a description of each field)

Table 23 ae/BC/Attachment Fields

Field Type Description

Attachment

name String The name of the attached data.

content-type String The attached data type. For example: application/binary.

content-id String A unique identifier for the attachment.

For outbound attachments with an empty name field as well as inbound attachments, TIBCO BusinessConnect ebXML Protocol automatically generates a random string for the attachment’s content-id.

content Binary The content of the attachment. This field takes precedence over the fileReference field.

Note: All text-based attachments must be encoded in UTF-8.

PartInfo N/A The information of this particular attachment.

fileReference String The absolute path to the file that contains the attachment. This field is ignored if the content field is not empty.

For inbound messages, TIBCO BusinessConnect ebXML Protocol uses this field to pass the reference of a large attachment. See Domains on page 31 for more information.



Table 24 ae/BC/TradingPartner Fields

Message Field Type Description

TradingPartner

name String The name of the trading participant.

domain String The domain of the trading participant.

id String The identity of the trading participant.


Configuring Private Processes with TIBCO ActiveMatrix BusinessWorks | 99

Configuring Private Processes with TIBCO ActiveMatrix

BusinessWorks

To define a TIBCO ActiveMatrix BusinessWorks private process to interact with BusinessConnect requires the following resources:

• BusinessConnect Connection (BCServerConfig) — a shared resource that connects to the BusinessConnect configuration store for the settings in TIBCO BusinessConnect ebXML Protocol.

• Activities (BusinessConnect Palette) to handle outbound and inbound BusinessConnect messages.

Configuring BCServerConfig Resource

In order for your private process to communicate with your BusinessConnect server, you must include exactly one BCServerConfig resource in the root project view.

Follow the instructions below to configure the BCServerConfig resource:

1. In TIBCO Designer, click Palettes in the menu bar and select Browse....

2. Select BusinessConnect under the BusinessConnect folder to make the BusinessConnect palette available.

3. Click Close.

4. Click the root project directory of your TIBCO ActiveMatrix BusinessWorks project.

5. Open the palette panel.

6. Drag a BusinessConnect Connection resource to the design panel.

You will see the resource in the design panel with the name "BCServerConfig". You can change its name in the configuration panel if you wish.

7. Click the BusinessConnect Server Access tab.

8. Select the JDBC driver you will use to communicate with the BusinessConnect configuration store in the JDBC Driver drop-down list.

The settings in step 8, step 9, and step 10 should be the same as the settings in your BusinessConnect installation. To see the JDBC settings in your BusinessConnect installation, log into TIBCO Administrator and go to BusinessConnect > System Settings > Audit, Non-Repudiation and Runtime Database Configuration, then select the bc-db connection alias.



9. Type the URL for the BusinessConnect configuration store in the JDBC URL field.

10. Type the configuration store username and password in the DB User and DB Password fields.

11. Click the Apply button.

12. Click the Configuration tab.

Note that the Update Transport Settings checkbox is selected. By default, the resource synchronizes its Rendezvous or JMS settings with the settings in the BusinessConnect configuration store.

13. Click the Update from Configuration Store button.

14. Click the Configuration tab and select ebMS3 from the Protocol Name drop-down list.

15. Click the Import Selected Business Protocol button. TIBCO Designer will now retrieve all installed operations in the BusinessConnect configuration store and place them in the BCSchemas project folder in the form of schemas.

16. Click Apply.

For more information on the BusinessConnect Connection (BCServerConfig) resource, see TIBCO BusinessConnect Palette Reference.

Configuring Send and Receive Activities

There are three BusinessConnect Send activities for sending requests (or receipts), responses and miscellaneous messages. There are also three BusinessConnect receive activities for receiving requests (or receipts), response, and miscellaneous messages.

When configuring a Send activity, you must ensure that all required fields are supplied to the activity before the Send activity can be executed. When a Send activity is executed, a private process message of the selected type of the selected operation is sent to BusinessConnect Interior Server.

Unlike Send activities, Receive activities are process starters. Therefore, there can be only one Receive activity in a process definition and the Receive activity acts to start the process. A process definition with the Receive start activity is invoked when BusinessConnect receives a message from a trading partner and sends it to TIBCO ActiveMatrix BusinessWorks, or when BusinessConnect creates an Acknowledgement or Advisory message and sends to private process when

Do not move, modify, or delete the BCSchemas folder or the contents therein.


Configuring Private Processes with TIBCO ActiveMatrix BusinessWorks | 101

certain event occurs. You can configure the process definition to use the output of the Receive activity to perform different tasks, such as formulating a response message and invoking a Send activity, or forwarding the received message to the downstream of your enterprise back office system for further processing.

For more information on configuring each of the Send and Receive activities, see TIBCO BusinessConnect Palette Reference. You can also step through the tutorial in Chapter 10, Tutorial, on page 113 to learn how to configure a TIBCO ActiveMatrix BusinessWorks project to send and receive ebMS3 messages.

The following sub-sections give you a quick glance at the resources you need to configure different kinds of private processes.

Configuring Initiators

In order for your TIBCO ActiveMatrix BusinessWorks processes to initiate ebMS3 transactions, you need the following resources:

• BCServerConfig — for connecting to your BusinessConnect server.

• Send Request/Notification — for sending request messages to trading partners.

• Receive Response (two way transaction only) — for receiving responses from trading partners.

• Receive Misc. Msg — for receiving acknowledgments, advisory signals, or error signals from BusinessConnect.

Configuring Responders

In order for your TIBCO ActiveMatrix BusinessWorks processes to receive request messages, you need the following resources:

• BCServerConfig — for connecting to your BusinessConnect server.

• Receive Request/Notification — for receiving request messages from trading partners.

• Send Response (two-way transaction only) — for sending response messages to BusinessConnect that forwards the response to the trading partner after processing and packaging.

• Receive Misc. Msg — for receiving acknowledgments, advisory signals, or error signals from BusinessConnect.


| 103

Chapter 9 Viewing Logs

This chapter discusses how to view audit, non-repudiation, and resend logs after conducting business transactions.

Topics

• Logging Overview, page 104

• Audit Log, page 105

• Non-Repudiation Log, page 107

• Resendable Transactions Log, page 108


104 | Chapter 9 Viewing Logs

Logging Overview

TIBCO BusinessConnect ebXML Protocol provides three logs that track which messages have been processed: audit log, non-repudiation log, and resend log. These logs are accessible in the log viewer. See Viewing Logs on page 104 for more information on accessing the log viewer.

The audit log is used to stored information about the ebMS3 transactions and documents processed by TIBCO BusinessConnect.

The non-repudiation log is used to provide proof of the delivery of messages and message content. It is a persistent record of all successfully completed transactions. You can configure any or all ebMS3 transactions to be stored into the non-repudiation log. This protects against any attempts by trading partners to subsequently deny the occurrence or content of the transaction. See Non-Repudiation Log on page 107 for more information.

The resend log displays the audit log transactions that are eligible to be resent, as well as a history of the resent messages. See Resendable Transactions Log on page 108 for more information.

Viewing Logs

Follow the instructions below to view logs of ebMS3 transactions in the log viewer:

1. Expand BusinessConnect > Log Viewer in the left panel.

2. Select ebMS3 in the Protocol list.

For information on searching the logs, see TIBCO BusinessConnect Trading Partner Administration.

3. Click one of the following buttons in the right panel to select which log to view: Audit, Non-Repudiation, Resendable Transactions, or Resend History.


Audit Log | 105

Audit Log

The audit log for ebXML protocol is used to store information about the messages and documents processed by TIBCO BusinessConnect ebXML Protocol. You can use the audit log to follow the processing states of inbound or outbound documents, as well as cancel pending transactions (see TIBCO BusinessConnect Trading Partner Administration for more information).

Information stored in the audit log for ebXML protocol includes sent and received documents, host and partner names, processing status, and errors and exceptions, and so on.

Summary View

Table 25 lists the columns that appear in the audit log.

Transaction Details View

To view the details of a transaction, click the icon in the left-most column of an audit log entry.

Table 25 Audit Log, Summary View Columns

Column Name Definition

Time Stamp The time when the message was processed.

Trading Partner The name of the trading partner in this transaction, as defined in the Participants panel in the BusinessConnect console.

Conversation ID The conversation ID of the transaction.

Sequence No N/A.

Operation ID The identifier of the transaction. For example: rosettanet.org/3A4/2.0/Request Purchase Order.

Tracking ID A string specified by the private process in the trackingID field of the corresponding ae/ebMS3/InitiatorRequest or ae/ebMS3/ResponderResponse message.

AgreementRef A string indicating the agreement that governs the transaction between the host and the trading partner.

Host Initiates Indicates whether the host participant initiated the transaction.



The Log Viewer first displays the general information for this transaction at the top and a table with information for all transaction states at the bottom. The table columns are listed in Table 26.

State Details View

The state details view offers the same information in the transaction view, but it shows the information for one state at a time.

There are two ways to see the state details view:

• Click the icon in the left-most column of a state entry.

• Click Change View at the upper-right corner to see the details of the first state in the transaction. You can see details of the next or previous state by clicking the Next or Previous button, respectively.

Table 26 Audit Log, Transaction Details View Columns

Column Definition

Time Stamp The time the transaction passed through the state displayed in the State column.

Status The status of the entire transaction at the particular state.

State The state of the transaction. See Advisory Signal Message Format on page 92.

Description A more verbose description of the state listed in the State column.

Message ID The unique identifier for the message that is processed at the state displayed in the State column.

Action The action used to process the inbound or outbound message.

Service The service that acts on the inbound or outbound message.


Non-Repudiation Log | 107

Non-Repudiation Log

Non-repudiation logging protects against any attempts by the sender of a document to subsequently deny the occurrence or content of the document. In TIBCO BusinessConnect ebXML Protocol, non-repudiation and digital signatures are coupled together by default.

In contrast to the audit information, non-repudiation information is intended for long-term storage, so there is only one entry per transaction. The non-repudiation log view does not display all the information that it stores for a transaction. For example, digital signatures are stored but not displayed.

Summary View

The non-repudiation log displays one transaction per row in the columns list in Table 27.

Table 27 Non-Repudiation Log Columns

Field Definition

Time Stamp Time this non-repudiation log entry was entered.

Trading Partner The name of the trading partner in this transaction, as defined in the Participants panel in the BusinessConnect console.


Sequence No N/A.


Trading Partner Domain

The domain value of the trading partner’s domain-identity pair.

Trading Partner ID The identity value in the trading partner’s domain-identity pair.



Resendable Transactions Log

The resend log displays the columns list in Table 28. Transactions in the following states are resendable:

• NOTIFICATION _FROM_PP

• REQUEST_FROM_PP

• REQUEST_SENT_TO_PP

Table 28 Resendable Transactions Log Columns

Column Definition


Trading Partner The trading partner name.


Sequence No N/A.


Host Initiates Indicates whether the host initiated the transaction.

Status The updated status of the transaction.

State The updated state of the transaction.

Description A more verbose description of the state listed in the State column.

Message ID The unique identifier for the message that is processed at the state displayed in the State column.


Action The action used to process the inbound or outbound message.

Service The service that acts on the inbound or outbound message.



Resendable Transactions Log | 109

Transaction States

A transaction goes through various states in its TIBCO BusinessConnect ebXML Protocol life cycle. See Table 29 for a description of each state.

Table 29 Transaction States

State Description

ACK_TO_PP Sent acknowledgment to private process for request or response message.

PACKAGED_ACK Packaged MSH receipt to trading partner.

PACKAGED_ERROR Packaged error to trading partner.

PACKAGED_EXCEPTION Packaged business-level exception to trading partner.

PACKAGED_NOTIFICATION Packaged notify document to trading partner.

PACKAGED_RECEIPT Packaged receipt acknowledgment to trading partner.

PACKAGED_REQUEST Packaged request document to trading partner.

PACKAGED_RESPONSE Packaged response document to trading partner.

MESSAGE_STORED Message has been stored to Store-and-Forward.

EXCEPTION_FROM_PP Received business-level exception from private process.

REQUEST_FROM_PP Received request document from private process.

RESPONSE_FROM_PP Received response document from private process.

RECEIPT_FROM_TP Received MSH receipt from trading partner.

DUP_ACK_FROM_TP Received duplicate MSH receipt from trading partner.

DUP_RECEIPT_FROM_TP Received duplicate receipt acknowledgment from trading partner.

DUP_REQUEST_FROM_TP Received duplicate request document from trading partner.

DUP_RESPONSE_FROM_TP Received duplicate response document from trading partner.

ERROR_FROM_TP Received error from trading partner, or unable to receive response from trading partner.

EXCEPTION_FROM_TP Received business-level exception from trading partner.



DUP_EXCEPTION_FROM_TP Received duplicate exception from trading partner.

RECEIPT_FROM_TP Received acknowledgment receipt from trading partner.

REQUEST_FROM_TP Received request document from trading partner.

RESPONSE_FROM_TP Received response document from trading partner.

DUP_NOTIFICATION_TO_TP Sending duplicate notify document to trading partner.

DUP_RECEIPT_TO_TP Sending duplicate acknowledgement receipt back to trading partner.

DUP_REQUEST_TO_TP Sending duplicate request document to trading partner.

DUP_RESPONSE_TO_TP Sending duplicate response document to trading partner.

DUP_NOTIFICATION_SENT_TO

_TPSent duplicate notify document to trading partner.

DUP_RECEIPT_SENT_TO_TP Sent duplicate acknowledgement receipt back to trading partner.

DUP_REQUEST_SENT_TO_TP Sent duplicate request document to trading partner.

DUP_RESPONSE_SENT_TO_TP Sent duplicate response document to trading partner.

REQUEST_SENT_TO_PP Sent request document to private process.

RESPONSE_SENT_TO_PP Sent response document to private process.

RECEIPT_SENT_TO_TP Sent MSH receipt to trading partner.

ERROR_SENT_TO_TP Sent error to trading partner.

EXCEPTION_SENT_TO_TP Sent business-level exception to trading partner.

DUP_EXCEPTION_SENT_TO_TP Sent duplicate exception to trading partner.

RECEIPT_SENT_TO_TP Sent receipt acknowledgment to trading partner.

REQUEST_SENT_TO_TP Sent request document to trading partner.

RESPONSE_SENT_TO_TP Sent response document to trading partner.

WAIT_TP_RESPONSE Timed out waiting for response document from trading partner.

Table 29 Transaction States (Cont’d)

State Description


Resendable Transactions Log | 111

WAIT_PP_RESPONSE Timed out waiting for response document from private process.

WAIT_TP_RECEIPT Timed out waiting for receipt acknowledgment from trading partner.

Table 29 Transaction States (Cont’d)

State Description



Resend History Log

The resend history log displays the columns list in Table 30.

Table 30 Resend History Log Columns

Column Definition


Trading Partner The trading partner name.


Sequence No N/A.




Host Initiates Indicates whether the host initiated the transaction.


| 113

Chapter 10 Tutorial

This tutorial guides you through the steps necessary for running the samples of TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 standard.

Topics

• Overview, page 114

• Setting Up the Sample, page 115

• Running the Sample, page 134


114 | Chapter 10 Tutorial

Overview

TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 standard provides the following two sample files:

• ebMS3Demo.zip

You can find it in the TIBCO_HOME\bc\6.1\protocols\ebxml\samples\ebMS3\tutorial\bw directory. This sample file is used to work with TIBCO ActiveMatrix BusinessWorks.

• ebms3_sample_operations.csx

You can find it in the TIBCO_HOME\bc\6.1\protocols\ebxml\samples\ebMS3\tutorial\inter

faces directory. This sample file is used to work with TIBCO Administrator.

Prerequisites

In order to use this tutorial, you must have done the following:

• Installed TIBCO ActiveMatrix BusinessWorks

• Installed TIBCO BusinessConnect

• Installed TIBCO BusinessConnect Service Plug-in after installing TIBCO BusinessConnect on the two machines so that the BusinessConnect Palette with BusinessWorks is installed.

• Created deployment configuration for BusinessConnect and fully deployed BusinessConnect. See TIBCO BusinessConnect Server Administration Guide for instructions.


Setting Up the Sample | 115

Setting Up the Sample

Before running the sample projects, you need to configure them in TIBCO Administrator and TIBCO ActiveMatrix BusinessWorks.

Setting Up the Sample in TIBCO Administrator

The section describes how to configure the sample in TIBCO Administrator.

Overview

There are two samples presented in this tutorial: one-way push and one-way pull.

Participant Information

See Table 31 for the participant information used in this tutorial.

Setting Up Buyer on Machine 1

This section gives the instructions for setting up the BusinessConnect server on Machine 1, which will act as the buyer in the transaction. The following is a general sketch of the tasks:

• Task A, Importing ebMS3 Operations, page 116

• Task B, Configuring Server Transport, page 116

• Task C, Configuring Trading Host, page 117

• Task D, Configuring Trading Partner, page 119

• Task E, Configuring Business Agreement, page 122

Table 31 Participant Information

Machine 1 Machine 2

Trading Partner Name Buyer Seller

Key Identity File bcpartner1_key.p12 bcpartner2_key.p12

Certificate file bcpartner1_cert.p7b bcpartner2_cert.p7b



Task A Importing ebMS3 Operations

Follow the instructions below to import the ebMS3 operations that will be used in the tutorial:

1. On Machine 1, log into TIBCO Administrator.

2. Expand BusinessConnect > Operations Editor in the left panel.


4. On the Import Operations page,

a. Click change. Then click Browse and navigate to TIBCO_HOME/bc/6.1/protocols/ebxml/samples/ebMS3/tutorial/int

erfaces/ebms3_sample_operations.csx. Click OK.

b. Leave the Password field empty.

c. Click Import.

5. Click Done.

Task B Configuring Server Transport

Follow the instructions below to configure the BusinessConnect server on Machine 1:

1. Expand BusinessConnect > System Settings in the left panel.

2. Click Inbound Public Transport Types in the right panel.

3. Check the HTTP, HTTPS and HTTPSCA checkboxes, and click the Enable button.

4. Click Save.

5. Expand BusinessConnect > Gateway in the left panel.

6. Click Gateway Services in the right panel.

7. Click New.

8. Type HTTP in the Name field, and select HTTP from the drop-down list of Type.

9. Click OK.

10. Click the Credentials button.

11. Click the New Private Key button.

12. Type Buyer Key in the alias field.

13. Click change and navigate to the following directory: TIBCO_HOME/bc/6.1/samples/keys.



14. Select bcpartner1_key.p12 and click OK.

15. Click the set link next to Password.

16. Type Password1 in both the Enter password and Enter password again fields.

17. Click OK.

18. Click Save.

19. Click OK in the warning message.

20. Click Done.

21. Click the Transport tab.

22. Select Buyer Key from the Private Key Credential for Secure Ports drop-down list.

Task C Configuring Trading Host

You will set up the buyer as a trading host, which consists of the following steps:

• Setting Up Trading Host Properties, page 117

• Setting Up ebMS3 Protocol, page 119

Setting Up Trading Host Properties

Follow the steps below to set up the trading host properties:

1. Expand BusinessConnect > Participants in the left panel.

2. Click the New button in the right panel.

3. Type Buyer in the Participant Name field.

4. Select Host in the Participant Type drop-down list.

5. Click OK.

6. Select the Active checkbox.

7. Click the Business Locations tab.

8. Click the Headquarters link.

Steps 7 to 18 are optional.



9. Specify the following information:

— Phone: 111-111-1111

— Fax: 111-111-1111

— Email: [email protected]

10. Click the New button in the Contacts area.


— First Name: Joe

— Last Name: Smith

— Contact Type: Legal

12. Click Save.

13. Select Joe Smith in the Primary Legal Contact drop-down list.

14. Click the New button in the Contacts area again.

15. Add another contact with the following information:

— First Name: Jane

— Last Name: Jones

— Contact Type: Support

16. Click Save.

17. Select Jane Jones in the Primary Support Contact drop-down list.

18. Click Save.

19. Click the Credentials tab.


21. Type Buyer Key in the Alias field.

22. Click the change link next to Current Credential.

23. Click Browse and navigate to the following directory: TIBCO_HOME/bc/6.1/samples/keys.

24. Select bcpartner1_key.p12 and click Open.

25. Click OK.



28. Click OK.



29. Click Save.

Setting Up ebMS3 Protocol

Follow the steps below to set up the trading host’s Protocols tab:



3. Follow the steps below to configure the General tab.

a. Click the Add New link next to the Default Domain Identity field.

b. Click the Add New button.

c. Select URI from the Domain drop-down list.

d. Type uri:buy123 in the Identity field.

e. Click Save.

f. Click OK.

g. Select URI-uri:buy123 from the Default Domain Identity drop-down list.


Checking Your Work


2. Click General in the right panel.

3. Confirm that Buyer is selected in the Default Host drop-down list.

4. Click Save.

Task D Configuring Trading Partner

Next, you will set up a trading partner configuration on Machine 1 for the seller, which consists of the following steps:

• Setting Up Trading Partner Properties, page 119


Setting Up Trading Partner Properties

Follow the steps below to set up the trading partner properties:





3. Type Seller in the Participant Name field.

4. Select Partner in the Participant Type drop-down list.

5. Click OK.





— Phone: 222-222-2222

— Fax: 222-222-2222




— First Name: Jack



12. Click Save.

13. Select Jack Smith in the Primary Legal Contact drop-down list.



— First Name: Jill



16. Click Save.

17. Select Jill Jones in the Primary Support Contact drop-down list.

18. Click Save.





20. Click the New Certificate button.

21. Type Seller Cert in the Alias field.



24. Select bcpartner2_cert.p7b and click Open.

25. Click OK.

26. Click Save.




a. Click Enable.


c. Click OK.






d. Type uri:sell123 in the Identity field.

e. Click Save.

f. Click OK.

g. Select URI-uri:sell123 from the Default Domain Identity drop-down list.

h. Type ebms3 in the AgreementRef field.



5. Click the Transports tab, then follow the steps below to configure this tab.

a. Click Add.

b. Type HTTP in the Transport Name field.

c. Select HTTP from the Transport Type drop-down list.

d. Click OK.

e. In the URL field, type hostname:6700/dmz/ebMS3, where hostname is the name of Machine 2, which will configure the seller as its trading host, and 6700 is the HTTP port set in the deployment configuration on Machine 2’s BusinessConnect server (see Configuring Server Transport on page 124).

6. Click Save three times to finish configuring this trading partner.

Task E Configuring Business Agreement

1. Expand BusinessConnect > Business Agreements in the left panel.


3. Select Buyer in the Host Party area and Seller in the Partner Party area.

4. Click OK.


6. Select the ebMS3 checkbox.

7. Click OK.


9. In the Operation Bindings tab, select the Allow All Operations checkbox. This allows the selected host and partner to initiate all ebMS3 transactions installed in the Operations Editor.

10. Click the Document Security tab.

11. Select Buyer Key in the Signing Key drop-down list.

12. Select Seller Cert in the Encryption Certificate drop-down list.

13. Select Seller Cert in the Verification Certificate drop-down list.

14. Select Buyer Key in the Decryption Key drop-down list.


16. In the Outbound Transports for Host 'Buyer' area, select HTTP from the Primary Transport drop-down list.

17. In the Allowed Inbound Transports for Partner 'Seller' area, make sure that the HTTP checkbox is selected.



18. Click Save twice to finish configuring this business agreement.

Task F Others

You still need to perform the following tasks:

1. Deploy BusinessConnect Server.

2. Start BusinessConnect Interior Server and Gateway Server.

See TIBCO BusinessConnect Interior Server Administration and TIBCO BusinessConnect Gateway Server Administration for more information.

Setting Up Seller on Machine 2

This section gives the instructions for setting up the BusinessConnect server on Machine 2, which will act as the seller in the transaction. The following is a general sketch of the tasks:

• Task A, Importing ebMS3 Operations, page 123

• Task B, Configuring Server Transport, page 124

• Task C, Configuring Trading Host, page 124

• Task D, Configuring Trading Partner, page 127

• Task E, Configuring Business Agreement, page 130

Task A Importing ebMS3 Operations

Follow the instructions below to import the ebMS3 operations that will be used in the transaction:

1. On Machine 2, log into TIBCO Administrator.

2. Expand BusinessConnect > Operations Editor in the left panel.


4. On the Import Operations page,

a. Click change. Then click Browse and navigate to TIBCO_HOME/bc/6.1/protocols/ebxml/samples/ebMS3/tutorial/int

erfaces/ebms3_sample_operations.csx. Click OK.

b. Leave the Password field empty.

c. Click Import.

5. Click Done.



Task B Configuring Server Transport

Follow the instructions below to configure the BusinessConnect server on Machine 2:


2. Click Inbound Public Transport Types in the right panel.

3. Check the HTTP, HTTPS and HTTPSCA checkboxes, and click the Enable button.

4. Click Save.

5. Expand BusinessConnect > Gateway in the left panel.

6. Click Gateway Services in the right panel.

7. Click New.

8. Type HTTP in the Name field, and select HTTP from the drop-down list of Type.

9. Click OK.

10. Click the Credentials button.


12. Type Seller Key in the alias field.

13. Click change and navigate to the following directory: TIBCO_HOME/bc/6.1/samples/keys.

14. Select bcpartner2_key.p12 and click OK.



17. Click OK.

18. Click Save.

19. Click OK in the warning message.

20. Click Done.

21. Click the Transport tab.

22. Select Seller Key from the Private Key Credential for Secure Ports drop-down list.

Task C Configuring Trading Host

You will set up the seller as a trading host, which consists of the following steps:



• Setting Up Trading Host Properties, page 125


Setting Up Trading Host Properties

Follow the steps below to set up the trading host properties:



3. Type Seller in the Participant Name field.

4. Select Host in the Participant Type drop-down list.

5. Click OK.





— Phone: 222-222-2222

— Fax: 222-222-2222




— First Name: Jack



12. Click Save.

13. Select Jack Smith in the Primary Legal Contact drop-down list.






— First Name: Jill



16. Click Save.

17. Select Jill Jones in the Primary Support Contact drop-down list.

18. Click Save.



21. Type Seller Key in the Alias field.



24. Select bcpartner2_key.p12 and click Open.

25. Click OK.



28. Click OK.

29. Click Save.


Follow the steps below to set up the trading host’s Protocols tab:









d. Type uri:sell123 in the Identity field.

e. Click Save.

f. Click OK.

g. Select URI-uri:sell123 from the Default Domain Identity drop-down list.


Checking Your Work


2. Click General link in the right panel.

3. Confirm that Seller is selected in the Default Host drop-down list.

4. Click Save.

Task D Configuring Trading Partner

Next, you will set up a trading partner configuration on Machine 2 for the buyer, which consists of the following steps:

• Setting Up Trading Partner Properties, page 127


Setting Up Trading Partner Properties

Follow the steps below to set up the trading partner properties:



3. Type Buyer in the Participant Name field.

4. Select Partner in the Participant Type drop-down list.

5. Click OK.







— Phone: 111-111-1111

— Fax: 111-111-1111




— First Name: Joe



12. Click Save.

13. Select Joe Smith in the Primary Legal Contact drop-down list.



— First Name: Jane



16. Click Save.

17. Select Jane Jones in the Primary Support Contact drop-down list.

18. Click Save.


20. Click the New Certificate button.

21. Type Buyer Cert in the Alias field.






24. Select bcpartner1_cert.p7b and click Open.

25. Click OK.

26. Click Save.




a. Click Enable.


c. Click OK.






d. Type uri:buy123 in the Identity field.

e. Click Save.

f. Click OK.

g. Select URI-uri:buy123 from the Default Domain Identity drop-down list.

h. Type ebms3 in the AgreementRef field.

5. Click the Transports tab, then follow the steps below to configure this tab.

a. Click Add.

b. Type HTTP in the Transport Name field.

c. Select HTTP from the Transport Type drop-down list.

d. Click OK.

e. In the URL field, type hostname:6700/dmz/ebMS3, where hostname is the name of Machine 1, which configures the buyer as its trading host, and 6700 is the HTTP port set in the deployment configuration on Machine 1’s BusinessConnect server (see Configuring Server Transport on page 116).

6. Click Save three times to finish configuring this trading partner.



Task E Configuring Business Agreement

1. Expand BusinessConnect > Business Agreements in the left panel.


3. Select Seller in the Host Party area and Buyer in the Partner Party area.

4. Click OK.


6. Select the ebMS3 checkbox.

7. Click OK.


9. On the Operation Bindings tab, select the Allow All Operations checkbox. This allows the selected host and partner to initiate all ebMS3 transactions installed in the Operations Editor.

10. Click the Document Security tab.

11. Select Seller Key in the Signing Key drop-down list.

12. Select Buyer Cert in the Encryption Certificate drop-down list.

13. Select Buyer Cert in the Verification Certificate drop-down list.

14. Select Seller Key in the Decryption Key drop-down list.


16. In the Outbound Transports for Host 'Seller' area, select HTTP from the Primary Transport drop-down list.

17. In the Allowed Inbound Transports for Partner 'Buyer' area, make sure that the HTTP checkbox is selected.

18. Click Save twice to finish configuring this business agreement.

Task F Configure an External User

1. Expand BusinessConnect > User Management > Users in the left panel.

2. Select the External tab, and click the Add button.

3. In the Email field, type [email protected].

4. In the Belongs to Partner drop-down list, select Buyer.

This task is only used for the one-way pull transaction tutorial.



5. Click OK.

6. Click the set link in the Password field, type exuser2 as the password.

7. Click OK, and then click Save.

Task G Others

You still need to perform the following tasks:

1. Deploy BusinessConnect Server.

2. Start BusinessConnect Interior Server and Gateway Server.

See TIBCO BusinessConnect Interior Server Administration and TIBCO BusinessConnect Gateway Server Administration for more information.

Setting Up the Sample in TIBCO ActiveMatrix BusinessWorks

To configure the sample in TIBCO ActiveMatrix BusinessWorks, complete the following tasks.

Task A Opening the Example Project

Follow the instructions below to set up the example project on the initiator and the responder machines:

1. Start TIBCO Designer.

2. Click New empty project.

3. Specify a directory for this new project or click the button to browse to an empty directory.

4. Click OK.

5. Click the Project menu in the menu bar of TIBCO Designer window and select Import Full Project.

6. Click the ZIP Archive tab in the Import Project dialog.

7. Click the button and navigate to the following directory: TIBCO_HOME/bc/6.1/protocols/ebxml/samples/ebMS3/tutorial/bw.

8. Select ebMS3Demo.zip and click Open.

9. Click OK.

10. In the Import - Options dialog, select the Try rename in case of name conflict radio button.



After the project finishes loading, you will see the main project view, as shown in Figure 9 on page 132.

Figure 9 TIBCO ActiveMatrix BusinessWorks Project

Task B Configuring the Example Project

Follow the instructions below to set up the example project.

1. Click the Global Variables tab.

2. Click the button.

3. Click the cell to the right of BCHOME (in the Value column) and type TIBCO_HOME/bc/6.1/.

4. Click OK.

5. Click the Project tab to view the project panel.



6. Click the root folder in the project panel. It is the name of the folder in which you saved your new project.

7. In the design panel, click the BC-ebMS3 icon . This is the BusinessConnect Connection shared resource your project uses to connect to your BusinessConnect server and the configuration store.

8. Click the BusinessConnect Server Access tab.

9. Specify JDBC Driver, JDBC URL, DB User, and DB Password.

JDBC settings here should be the same as the settings in your BusinessConnect installation. To see the JDBC settings in your BusinessConnect installation, log into TIBCO Administrator and go to BusinessConnect > System Settings > Audit, Non-Repudiation and Runtime Database Configuration; then select the bc-db connection alias.

10. Click the Apply button.

11. Click the Configuration tab.

12. If the Update Transport Settings checkbox is not selected, select it.

13. Click the Update from Configuration Store button.

14. Select ebMS3 from the Protocol Name drop-down list.

15. Click the Import Selected Business Protocol button. You should now see all installed ebMS3 operations in the BusinessConnect configuration store.

16. Click Apply.

17. Click the Save button to save the project.



Running the Sample

There are two sample transactions introduced in this tutorial:

• One-Way Push Transaction

• One-Way Pull Transaction

One-Way Push Transaction

This section describes the processes defined for the one-way push transaction.

This example contains the following processes in TIBCO Designer:

• Send One Way Push Message

• Receive Pushed Message

Send One Way Push Message

You will be using the Send One Way Push Message process definition on Machine 1 to initiate a one-way push transaction. This process definition can be accessed from the TIBCO Designer project panel in the Initiator folder. It reads a request from a local directory and sends the document to the BusinessConnect server via the request.


Running the Sample | 135

Receive Pushed Message

You will be using the Receive Pushed Message process definition on Machine 2 to respond to the push request message. This process definition can be accessed from the TIBCO Designer project panel in the Responder folder.

Running One-Way Push Transaction

To run this example, complete the following tasks:

Task A Running Receive Push Message on Machine 2

Follow the instructions below to start the Receive Request process definition on Machine 2:

1. In the opened TIBCO Designer project on Machine 2, select the Responder folder.

2. Double-click the Receive Pushed Message process definition in the design panel.

3. Click the Receive Request resource.

4. In the configuration tab, select rosettanet.org/3A7/1.3/Notify Of Purchase Order Acceptance in the Operation Name drop-down list.

5. Click Apply.

6. Select the Tester tab in the project panel.


8. Select the Responder > Receive Pushed Message process definition.

9. Click Load Selected.



Task B Running Send one Way Push Message on Machine 1

You must start Receive Pushed Message on Machine 2 prior to proceeding with this section. Follow the instructions below to start the Send one Way Push Message process definition on Machine 1:

1. In the open TIBCO Designer project on Machine 1, select the Initiator folder.

2. Double-click the Send one Way Push Message process definition in the design panel.

3. Click the Send Purchase Order Acceptance resource.


5. In the Input tab, type Seller in the tpName field.

6. Click Apply.

7. Click the Tester tab in the project panel.


9. Select the Initiator > Send one Way Push Message process definition.


Expected Results

If everything works as expected, the one-way push request is sent to the trading partner, the process turns green, and then the process ends on Machine 1.

Machine 2 receives a push request from the trading partner and the process turns green, then the process ends.

One-Way Pull Transaction

This section describes the processes defined for the one-way pull transaction.

This example contains the following processes in TIBCO Designer:

• Send UserMessage to be Pulled

• Send One Way Pull Request



Send UserMessage to be Pulled

You will be using the SendUserMessage to be Pulled process definition to send a user message to the BusinessConnect server on Machine 2. This process definition can be accessed from the TIBCO Designer project panel in the Initiator folder.

Send One Way Pull Request

You will be using the Send One Way Pull Request process definition on Machine 1 to send a pull request to the trading partner. This process definition can be accessed from the TIBCO Designer project panel in the Initiator folder.

Running One-Way Pull Transaction

To run this example, complete the following tasks:

Task A Running SendUserMessage to be Pulled on Machine 2

Follow the instructions below to start the SendUserMessage to be Pulled process definition on Machine 2:

1. In the opened TIBCO Designer project on Machine 2, select the Initiator folder.



2. Double-click the SendUserMessage to be Pulled process definition in the design panel.

3. Click the Send UserMessage for Pulling resource.


5. In the Input tab:

— set the tpName attribute to Buyer

— set the toBePulled attribute to true

— provide an valid URI in the mpc field

— provide the username for this message

The user name provided must match the external user that you configured on Machine 2’s Administrator and associated with the trading partner Buyer. If you follow the instructions, the user name should be "[email protected]". See Task F, Configure an External User for more information.

Therefore, the message will be saved into Store-and-Forward on Machine 2, that is targeted to be pulled by the trading partner Buyer from this MPC channel.

6. Click Apply.

7. Select the Tester tab in the project panel.


9. Select the Initiator > SendUserMessage to be Pulled process definition.


Task B Running Send One Way Pull Request on Machine 1

Follow the instructions below to start the Send One Way Pull Request definition on Machine 1:

1. In the open TIBCO Designer project on Machine 1, select the Initiator folder.

2. Double-click the Send One Way Pull Request process definition in the design panel.

3. Click the Send Pull Request resource.

4. In the configuration panel below, select tibco.com/EBMS Pull Request/1.0: Pull Request in the Operation Name drop-down list.



5. In the Input tab:

— set the tpName attribute to Seller

— provide an valid URI in the mpc field

— provide the username and password

provide the same user name and password you set for the Send UserMessage for Pulling activity. The user name and password defined in the Global Variables must match the ones you configured on Machine 2 in TIBCO Administrator when you define the external user and associate with the trading partner Buyer.

6. Click Apply.

7. Click the Tester tab in the project panel.


9. Select the Initiator > Send One Way Pull Request process definition.


11. Click OK to start the tester.

Expected Results

If everything works as expected, you will observe the following sequence of events:

1. The user message is sent to BusinessConnect successfully. Internally the message will be processed and packaged and stored in Store-and-Forward, which is targeted to be pulled by the trading partner Buyer from this MPC channel.

2. BusinessConnect on Machine 2 retrieves the user message from the specified mpc with the specified username and password, then sends back the user message with matched MPC/username/password to Machine1, and the private process on Machine 1 should receive the pulled message.


| 141

Appendix A Status Codes

This appendix describes status codes used by TIBCO BusinessConnect ebXML Protocol ebMS3/AS4 standard. 200~699 are standard HTTP codes and BusinessConnect-defined codes, while 1100~4999 are codes defined by TIBCO BusinessConnect ebXML Protocol.

These status codes and their descriptions appear in the following locations:

• Private messages The following private message classes include the statusCode and statusMsg fields. See Private Process Message Formats on page 73 for more information:

— ae/ebMS3/InitiatorRequest

— ae/ebMS3/InitiatorResponse

— ae/ebMS3/Advisory (for both error and advisory signal messages)

• Audit log The Description field in the transaction detail view may display a status code with accompanying description. See Transaction Details View on page 105 for more information.

Table 32 Status Codes (Sheet 1 of 12)

Code(statusCode field)

Description(statusMsg field)

Role Comment

200 OK HTTP(S)

201~299 HTTP(S) OK codes HTTP(S)

300~503 HTTP(S) error codes HTTP(S)

510 No valid HTTP response. HTTP(S) The most likely causes are that the trading partner sent a trading partner identity that was not recognized by TIBCO BusinessConnect, or that the trading partner did not send a proper HTTP response.


142 | Appendix A Status Codes

699 Failed to connect to trading partner. BusinessConnect

1100 Received

[request|response|error]

message from TP.

Information

1101 Received [signed|] [encrypted|]

[sync/async|] [action|] from

TP.

Information

1102 Ignoring

[Request/response|Receipt

Acknowledgment|MSH

Acknowledgment] message.

Reason: detailed_description.

Information

1651 Receipt Acknowledgment received

for message ID: message_id.

Information The trading partner has received a Receipt Acknowledgment for the indicated message.

1652 Acceptance Acknowledgment

received for message ID:

message_id.

Information

1653 MSH Acknowledgment received for

message ID: message_id.

Information The trading partner has sent an MSH Acknowledgment for the indicated message.

1999 Info: detailed_description. Information

2999 Warning: detailed_description. Warning

3101 Missing either operation ID or

To TP name.

Error

3102 Configuration read error.


Error




Role Comment


Status Codes | 143

3103 Operation not allowed. Reason:

detailed_description.

Error

3104 Host Identity for

Authentication not configured -

message cannot be signed.

Error

3105 To or From Role not specified -

receipt acknowledgment cannot

be constructed.

Error

3106 Partner Identity for

trading_partner_name not configured

- [Request|Response|Receipt|

MshAck|Error|Exception] cannot

be [signed|encrypted].

Error

3107 Config read failed for remote

TP. Reason: detailed_description.

Error

3108 Config read failed for response

action from TP.

Error

3109 Inconsistency between

configuration and message.


Error

3110 Unknown Service Action.

Service=service Service

type=service_type Action=action.

Error

3111 To party Domain domain and

Identity identity does not match

with configuration.

Error

3112 Host not allowed to send the

response to TP trading_partner_name.


Error




Role Comment



3113 Failed to determine the

transport. Reason:


Error

3114 Private process supplied

'businessDocumentName' of

businessDocumentName does not

match configured names of

name_in_GUI.

Error

3115 Message ordering is only

available for transactions with

Once-And-Only-Once semantics

and SyncReplyMode of 'none'.

Error

3116 'MessageOrder' element must not

be present with the 'SyncReply'

element.

Error

3117 Time To Live expired Error

3118 Failed to get payload against

the manifest. Reason:


Error

3119 CPAId cpa_id does not match with

configuration.

Error

3120 Version business_process_version is

not supported.

Error

3121 From party Domain domain and

Identity identity does not match

with configuration.

Error

3122 CPAID in CPA and EBMS3 document does not match.

Error

3123 Authorization info is missing when mpc is specified by back office for Pull Request message.

Error




Role Comment


Status Codes | 145

3124 Password is missing when mpc is

specified by back office for

Pull Request.

Error

3125 The Receipt has been received for a message that was previously sent by the MSH Invalid.

Error

3201 Post aborted - exhausted

maximum number of retries

(max_retries).

Error max_retries is the maxiumum number of retries configured in the GUI.

3202 Unknown Error while sending


Acknowledgment|MSH

Acknowledgment].

Error

3203 Posting to trading_partner_name

failed with code http_return_code.


Error

3204 The MSH is experiencing

temporary or permanent failure

in trying to open a transport

connection with a remote MSH.

Error The same as EBMS: 0005.

See ebMS Errors on page 27 for more information.

3301 Timed out waiting for

[sync|async]

[Acknowledgment|Receipt

Acknowledgment|Acceptance

Acknowledgment].

Error

3302 Unexpected error while waiting

for async response. Reason:


Error




Role Comment



3303 No MSH Acknowledgment received

after exhausting sending max.

number of retries (max_retries).

Error max_retries is the maxiumum number of retries configured in the GUI.

3304 No response data was received

from trading partner.

Error

3305 No MSH Receipt received after

sending back pulled message.

Error

3401 MIME formatting error. Reason:


Error

3402 EBMS3 SOAP envelope generation

error. Reason: detailed_description.

Error

3403 Failed to create MSH Ack

Envelope. Reason:


Error

3404 Failed to create Receipt

acknowledgment. Reason:


Error

3405 Failed to create Attachment

Sequence. Reason:


Error

3501 Client authentication failed

for Service=service Action=action.


Error

3502 [S/MIME|XML] Encryption failed



[S/MIME|XML] Encryption failed.


Error

3502-1 [S/MIME|XML] Encryption failed. Reason: detailed_description.

Error Short error message for 3502.




Role Comment


Status Codes | 147

3503 [S/MIME|XML] Decryption failed



[S/MIME|XML] Decryption failed.


Error

3503-1 [S/MIME|XML] Decryption failed. Reason: detailed_description.


3504 EBMS3 SOAP envelope signing

failed for Service=service

Action=action. Reason:


Error

3504-1 EBMS3 SOAP envelope signing

failed. Reason: detailed_description.


3505 EBMS3 SOAP envelope signature

verification failed for

Service=service Action=action.


Error

3505-1 EBMS3 SOAP envelope signature

verification failed.Reason:



3506 MSH Acknowledgment signature

references verification failed.

Error

3507 Receipt Acknowledgment NR

digests verification failed.


Error

3508 UsernameToken Authentication Procesing failed for Service=service Action=action. Reason: detailed_description.

Error

3509 WSS Security Procesing failed for Service=service Action=action. Reason: detailed_description.

Error




Role Comment



3601 MIME message parsing error.


Error

3602 EBMS3 SOAP envelope parsing


Error

3603 Error while processing response

from TP. Reason: detailed_description.

Error

3604 Unable to compute the operation

ID from message.

Error

3605 Failed to validate EBMS3

envelope parameters against

configuration. Reason:


Error

3606 Inbound Payload/Attachments

extraction error. Reason:


Error

3607 Incorect RefToMessageId for


Acknowledgment|MSH

Acknowledgment] message.

Error

3608 Sync Response Initialization

failed.

Error

3609 Failed to process Synchronous

[response|MSH Acknowledgment].

Error

3610 Error while sending request to

private process. Reason:


Error

3611 Timeout waiting for

[response|acknowledgment] from

private process.

Error




Role Comment


Status Codes | 149

3612 SOAP Fault (code:

[server|client], text:

brief_description, actor: actor,

details: detailed_description).

Error

3613 MSH Error (severity:

[Warning|Error]).

Error msh_error_code is one of the MSH error codes defined by the ebMS specifications.

3614 Application supplied a

duplicate message ID.

Error

3615 Could not find expected SOAP

Fault message.

Error

3616 Unexpected error while

processing sequenced messages.


Error

3617 Received message missing

expected SequenceNumber.

Error

3618 Sequenced message timed out

while queued.

Error

3619 Application supplied a

duplicate message ID - not

allowed for Once-And-Only-Once

semantics.

Error

3620 Sequenced message timed out

while received.

Error

3621 HTTP reply doesn't include a

content but status code is not

204.

Warning

3622 There is no message for mpc: mpcuri.

Error




Role Comment



3623 There is no message available for pulling, mpc= mpcuri.

Error

3624 The Receipt has not been

received for message: message

description.

Error

3650 Generic Exception received for

messageID: message_id. Reason:


Error Used by the responder private process to indicate that an exception occurred while processing an inbound request.

See Outbound Response Format on page 87 for more information.

3651 Receipt Exception received for

messageID: message_id. Reason:


Error

3652 Acceptance Exception received

for messageID: message_id.


Error Used by the responder private process to indicate that an exception occurred while processing an inbound request.

See Outbound Response Format on page 87 for more information.

3691 Processing failed for

Service=service Action=action.


Error




Role Comment


Status Codes | 151

3692 Failed to process [MSH|Receipt]

Acknowledgment for

[request|response|Receipt

Acknowledgment]. Reason:


Error

3699 General processing error:


Error

3701 Reliable storage insert failed.


Error

3702 Reliable storage update failed.


Error

3703 Reliable storage query failed.


Error

3801 EBMS3 SOAP envelope validation


Error

3802 [Incoming|Outgoing] request

payload failed schema

validation. Reason:


Error

3803 [Incoming|Outgoing] response

payload failed schema

validation. Reason:


Error

3804 Receipt acknowledgment failed

schema validation.

Error

3805 Missing schema URI for

validation.

Error

3806 Message validation error.


Error




Role Comment



3807 Exception message failed schema

validation. Reason:


Error

3808 Processing Mode mismatch. Error

3901 Reply to DMZ failed. Reason:


Error

3991 Unkown Internal Engine Error.


Error

3992 Missing error details resource.

Reason for original error:


Error Failed to find the error description resource. This is most likely due to packaging error.

3993 RefId does not exist. Error

3994 The digest associated does not match the signature digest for NRR.

Error

3995 code: code, short description: description, severity: severity,

category: category, origin: origin,

refMessageID: refmessageid, error

detail: error detail, description: description.

Error The EBMS3 standard errors.

See ebMS Errors on page 27 for more information.

4999 Debug: detailed_description. Error




Role Comment


| 153

Appendix B Property Reference

Table 33 lists the properties you can set in the BusinessConnect > System Settings > Activated Protocol Plug-ins and Properties > ebXML panel in the BusinessConnect console.

Table 33 Property Reference

Property Description

ebxml.fileref.threshold (In bytes) Content size threshold to use file reference in sending messages to private process. The default value is 5 MB (5000000).

ebms3.persist.duration (In minutes) Minimum length of time that the data from a sent message is kept in persistent storage by a receiving MSH. The default value is 120 minutes.

ebxml.sequence.pollInterval (In microseconds) The interval at which TIBCO BusinessConnect ebXML Protocol polls for queued messages that are ready to be dispatched and messages that have expired. The default value is 300 milliseconds.

ebxml.duns.check Enforce the correct identity format in the Participants configuration panel when the DUNS domain is used. Select duns to enforce a nine-digit DUNS number, duns+4 to enforce a thirteen-digit DUNS number, and none to turn off this feature.


154 | Appendix B Property Reference


| 155

Appendix C Smart Routing

TIBCO BusinessConnect enables you to define business rules to route messages to specific private processes. This feature is called smart routing, which requires configuration of the BusinessConnect server through the BusinessConnect console, as well as configuration of the BusinessConnect palette resources in TIBCO Designer. In the BusinessConnect console, you can set up the business rules and specify the smart ID to be assigned to messages that meet the conditions of the rule. In the BusinessConnect palette resources, you can configure which private processes will receive messages that include specific smart IDs

To configure the smart routing fields, select BusinessConnect > System Settings > Private Process Smart Routing > Add.

Table 34 Smart Routing Fields for ebMS3

Field Description

Enabled Check this checkbox to enable private process smart routing.

Protocol The business protocol for the message. Use the asterisk character (*) to match all protocols.

This is a required field.

From The domain identity for the trading partner that sends the original message. If Host (your company) sends a request to Partner and Partner sends a response, you may want to use smart routing for the response. In this case, the from field is matched by Host because Host is the originator of the business transaction.

Use the asterisk character (*) to match all hosts and partners, but do not use the asterisk character with a string. For example, do not use TIB*.


To The domain identity for the trading partner that receives the original message. If Partner sends a request to Host (your company), you may want to use smart routing for the request. In this case, the To field is matched by Host because Host is the recipient of the request.

Use the asterisk character (*) to match all hosts and partners, but do not use the asterisk character with a string. For example, do not use TIB*.



156 | Appendix C Smart Routing

Direction The business direction of the message: inbound or outbound. For example, if Partner sends a request to Host (your company), both the business direction and the message direction are inbound. However, if Host sends a request to Partner and Partner sends a response, the message direction of the response is inbound, but the business direction of the response is outbound because the original message was outbound.

The asterisk character (*) matches both directions. This is a required field.

Operation ID The location and identifier of the operation. This takes the form of a series of nodes.

Use one asterisk character (*) to match all operations directly under a specific node. For example:

BC/*/* matches BC/MyNotify/Test but not BC/MyNotify/Test/notify1

Use two asterisk characters (**) to match operations recursively. Use double asterisks alone or use them as the last node. For example:

BC/MyNotify/** matches BC/MyNotify/1.3/Test

BC/MyNotify/**/notify1 is the same as BC/MyNotify/**. The software ignores any nodes after a double asterisk.

You can use both a single asterisk and a double asterisk, for example:

BC/*/1.0/** matches BC/Test-01/1.0/A/B


CMName The name of the listening certified messaging (CM) transport for the private process. This is optional. If you provide the CM name for the listening CM transport, BusinessConnect pre-registers the CM name, assuring creation of a ledger and persistence of messages in the event that the listening transport is down. If the CM name is not pre-registered, and BusinessConnect has not yet had an opportunity to create a ledger, and the listening CM transport is down, messages do not persist.

Note: Do not use the asterisk character (*) in this field.

Note: Verify the accuracy of the CM name before deploying the rule. If the CM name you provide does not exist, the ledger will grow indefinitely.

For more information about CM listeners and CM names, see TIBCO Rendezvous Concepts.

Table 34 Smart Routing Fields for ebMS3 (Cont’d)

Field Description


Smart Routing | 157

Smart ID An identifier that indicates which smart routing rules the message satisfied. Any combination of alphanumeric characters is allowed, with a minimum of one character and a recommended maximum of twenty-five characters.


Table 34 Smart Routing Fields for ebMS3 (Cont’d)

Field Description


158 | Appendix C Smart Routing


| 159

Appendix D Public Messages

This appendix describes the elements and attributes in the ebMS3 messages and how they correspond to GUI elements in the BusinessConnect console or to private message fields.

Topics

• ebMS3 Public Message Structure, page 160

• SOAP Envelope, page 162


160 | Appendix D Public Messages

ebMS3 Public Message Structure

The structure of an ebMS user messa3ge is shown in Figure 10 below:

Figure 10 ebMS3 User Message Structure

Underlying Protocol Envelope (HTTP, SMTP,...)

SOAP with Attachments MIME Envelope

MIME Part

SOAP Envelope

SOAP Header

eb:UserMessage

eb:MessageInfo

MIME Part(s)

Payload(s)

Payload(s)

SOAP Body

eb:Messaging

eb:UserMessage

eb:MessageInfo

eb:PartyInfo

eb:CollaborationInfo

eb:MessageProperties

eb:PayloadInfo

WSS: Security

Wsr:Reliability / wsrm: ReliableMessaging

Wsr:Reliabiligy and wsrm:ReliableMessaging are not implemented because they are not required by AS4 profile.


ebMS3 Public Message Structure | 161

The structure of an ebMS3 signal message is shown in Figure 11 below:

Figure 11 ebMS3 Signal Message Structure

Underlying Protocol Envelope (HTTP, SMTP,...)

SOAP with Attachments MIME Envelope

MIME Part

SOAP Envelope

SOAP Header

eb:UserMessage

eb:MessageInfo

SOAP Body

eb:Messaging

eb:SignalMessage

eb:MessageInfo

eb:PullRequestOr

eb: ReceiptOr

eb:Error

WSS: Security

Wsr:Reliability / wsrm: ReliableMessaging

Wsr:Reliabiligy and wsrm:ReliableMessaging are not implemented because they are not required by AS4 profile.



SOAP Envelope

This section describes the elements and attributes in the ebXML SOAP envelope and how they correspond to GUI elements in the BusinessConnect console or to private message fields.

UserMessage Element

The UserMessage element, as defined by the ebXML Message Service Specification version 3.0, is shown in the following diagram.


SOAP Envelope | 163

See Table 35 for each element or attribute’s corresponding GUI element in the BusinessConnect console or corresponding private message field.

Table 35 UserMessage Element in ebMS3 Messages

Element/Attribute Source of Value

mpc identifies the message partitioning channel to which the message is assigned.

MessageInfo

Timestamp (Outbound message only) Automatically generated by TIBCO BusinessConnect ebXML Protocol.

MessageId (Outbound message only) The messageID field in the ae/ebMS3/InitiatorRequest message class. If a value is not specified there, then TIBCO BusinessConnect ebXML Protocol randomly generates one. See Outbound Request Format on page 74 for more information.

RefToMessageId The MessageData/MessageId element in the related inbound message. This element is not included in request messages.

PartyInfo

From/PartyId The ID string (without the domain string) in

Participants > participant > Protocols > ebMS3 > General > Default Domain Identity.

From/PartyId/type The domain string (without the ID string) in


Note: For outbound messages, this attribute is not included if the domain string is URI.

From/Role Operations Editor > ebMS3 > transaction > nameTransaction tab > Roles > Initiating Role (or Responding Role).

Or, in the case of override in operation binding:

Business Agreements > agreement > ebMS3 > Operation Bindings > transaction > Initiating Role. Note that if this field is empty, then the From/Role element is not included. See Operation Settings Tab on page 64 for more information.



To/PartyId The ID string (without the domain string) in


To/PartyId/type The domain string (without the ID string) in


Note: For outbound messages, this attribute is not included if the domain string is URI.

To/Role Operations Editor > ebMS3 > transaction > nameTransaction > Roles > Initiating Role (or Responding Role).

Or, in the case of override in operation binding:

Business Agreements > agreement > ebMS3 > Operation Binding > transaction > Initiating Role. Note that if this field is empty, then the To/Role element is not included. See Operation Settings Tab on page 64 for more information.

CollaborationInfo

AgreementRef/type Participants > Partner > Protocols > ebMS3 > General > AgreementRef.

AgreementRef/pmode Operations Editor > ebMS3 > transaction > nameTransaction > Service Information > PMode ID. This value can be overriden in Business Agreement Operation Binding.

Service Operations Editor > ebMS3 > transaction > nameTransaction > Service Information > Service.

Service/type Operations Editor > ebMS3 > transaction > nameTransaction > Service Information > Service Type.

Action Operations Editor > ebMS3 > transaction > nameAction > General > Name.

ConversationId (Outbound message only) The conversationID field in the ae/ebMS3/InitiatorRequest message class. If a value is not specified there, then TIBCO BusinessConnect ebXML Protocol randomly generates one in the outbound sequenced message. See Outbound Request Format on page 74 for more information.

Table 35 UserMessage Element in ebMS3 Messages (Cont’d)



SOAP Envelope | 165

MessageProperties

Property/name The property name of the message that must be agreed upon between partners.

PayloadInfo

PartInfo The supplemental information of a payload, either the payload in SOAP Body, or a payload in an attachment.

PartInfo/href The reference of the payload for which this PartyInfo is related. For outbound messages, it can be specified from the private process or automatically generated by TIBCO BusinessConnect ebXML Protocol.

PartInfo/Schema The schema of the payload. Customer can use this file to specify the schema URI which may be useful to the recipient.

PartInfo/Description A short description of the related payload and can be specified from private process.

PartInfo/PartProperties/Property

The customer property name and value pairs regarding this payload that can be specified by the sender.

Table 35 UserMessage Element in ebMS3 Messages (Cont’d)




SignalMessage Element

The SignalMessage element, as defined by the ebXML Message Service Specification version 3.0, is shown in the following diagram.

See Table 36 for each element or attribute’s corresponding GUI element in the BusinessConnect console or corresponding private message field.

Table 36 Signal Message Element in ebMS3 Messages


any Not included.

MessageInfo

Timestamp (Outbound message only) Automatically generated by TIBCO BusinessConnect ebXML Protocol.


SOAP Envelope | 167

MessageId (Outbound message only) The messageID field in the ae/ebMS3/InitiatorRequest message class. If a value is not specified there, then TIBCO BusinessConnect ebXML Protocol randomly generates one. See Outbound Request Format on page 74 for more information.

RefToMessageId The MessageData/MessageId element in the related inbound message. This element is not included in request messages.

PullRequest

mpc identifies the message partitioning channel to which the message is assigned.

any Not included.

Receipt

any A single ebbpsig:NonRepudiationInformation child element or a copy of the original user message element.

Error

Description A narrative description of the error in the language defined by the xml:lang attribute.

ErrorDetail The detailed description of the error message.

Error/category The type of the error, for example, Content, Packaging, UnPackaging, Communication, and InternalProcess.

Error/refToMessageInError

The MessageId of the message in the error, for which this error is raised.

Error/errorCode The unique identifier for the type of error.

Error/origin The functional module within which the error occurred. Possible values for this attribute include ebMS, reliability, and security.

Error/severity The severity of the error. Possible values are warning and failure.

Error/shortDescription The short description of the error.

Table 36 Signal Message Element in ebMS3 Messages (Cont’d)



| 169

Index

A

ackSignatureRequested 89

ae/ebMS3/Advisory 92, 95

ae/ebMS3/Initiator/Ack 79

ae/ebMS3/InitiatorRequest 74

ae/ebMS3/InitiatorResponse 81

ae/ebMS3/ResponderAck 90

ae/ebMS3/ResponderRequest 84

ae/ebMS3/ResponderResponse 87

architecture, product 3

attachment directory 31

audit log 104, 105, 105

state details view 106

summary view 105

audit log (see logs) 104

B

BCServerConfig 99

business agreement

document security properties 66

overriding participant settings 70

business agreements 61

configuring transports 68

operation bindings 63

protocol configuration 62

business agreements, configuring 62

Business Process Specification Schema 3

BusinessConnection Connection resource 99

C

certificate 30

certificates 30

checking DUNS digits 153

Collaboration Protocol Profile and Agreement 3

compression 38, 46

configuring BusinessConnect server 31

transport 31

conversation 54, 77, 80, 83, 87, 91, 95, 96

customer support xvii, xvii

D

digital signatures 38, 41, 43, 44, 46, 49, 66, 89

digest algorithm 66

verifying certificates 67

document security 66, 66

domain identities 30, 54, 55, 59, 59

adding 55, 59

in private messages 75, 75, 75

URI 55, 60

domains 31

DUNS digit check 153

duplicate elimination 40, 43, 48, 78, 89

E

ebMS3 overview 2

ebms3.persist.duration 153

ebxml.duns.check 153

ebxml.fileref.threshold 153

ebxml.sequence.pollInterval 153

encryption 37, 46, 66

algorithm 66

certificates 66

decrypting inbound message 67

error handling 26

exceptions 88, 93


170 | Index

exchanging information with trading partners 30

expired conversation 54

F

features 5

H

host transport 31

HTTP 31, 69

HTTPS 31, 60, 69

HTTPSCA 31, 60, 69

J

JMS message format 73

K

key 30

L

large payload 31

logs 104

audit log 104, 105, 105

non-repudiation log 104, 107, 107

overview 104

resend log 104

viewing 104

M

max response wait time 42, 46

maximum number of retries 41, 49

N

non-repudiation 38, 41, 43, 44, 46, 49

non-repudiation log (see logs) 104, 104, 107, 107

non-repudiation logging 63

configuring 63

O

one-way pull transaction 41

one-way push transaction 36

operation bindings 63

Action Settings tab 65

editing 63

overriding operation settings 64

Transports tab 65

operation bindings (see also business agreements) 63

Operations Editor 34

adding business processes 35

adding operations 35

adding organizations 35

adding transactions 36

adding versions 35

exporting transactions 50

importing transactions 34, 51

override

action settings 65

actions 65

default operation settings 64

participant settings 70, 70

transactions 64

transports 65, 65, 69, 69


Index | 171

P

party id 30

P-Mode ID 37, 42, 45

preparing to use TIBCO BusinessConnect RosettaNet

Protocol 29

private message formats

advisory signal 92

attachment 97

error message 95

inbound request 84

inbound response 81

outbound request 74

outbound response 87

request acknowledgment 79

response acknowledgment 90

TradingPartner 98

private messages 8, 8, 73, 73

89

ackRequested 89

action 85, 94

agreementRef 80, 83, 86, 91, 94

attachment 77, 83, 86, 89

content 97

content-id 97

content-type 97

fileReference 97

name 97

businessProcess 76, 80, 82, 85, 91, 94, 96

businessProcessVersion 76, 80, 82, 85, 91, 94, 96

closure 79, 81, 84, 87, 89, 91, 94, 96

conversationID 77, 80, 83, 87, 91, 95, 96

details 94

dupElimination 78, 89

error 26

extraInfo 94

fromRole 82, 85

fromTP 82, 85

host 80, 82, 85, 91, 93, 96

hostDomain 75

hostID 75

inbound response 26

JMS format 73

messageID 78, 80, 84, 87, 89, 92, 95, 96

operationID 76, 80, 82, 85, 91, 93, 96

operationType 91

organization 76, 80, 82, 85, 91, 94, 96

outbound response acknowledgment 26, 26

Rendezvous format 73

request 77, 86

response 83, 88

service 85, 94, 96

serviceType 85, 94

standardID 74, 80, 82, 85, 88, 90, 92, 95

statusCode 82, 88, 91, 93, 96

statusMsg 82, 88, 91, 93, 96

TIBCO ActiveMatrix BusinessWorks 99

toRole 82, 85

tpDomain 75

tpName 75, 80, 93, 95

trackingID 79, 81, 84, 90, 92, 95

TradingPartner

domain 98

id 98

name 98

tradingPartner 80, 90, 93, 96

transactionID 93

transactionName 77, 80, 82, 85, 91, 94, 96

private processes 8, 71, 72

message formats (see private messages) 73

standalone 72

TIBCO ActiveMatrix BusinessWorks


172 | Index

configuring initiators 101

configuring responders 101

Send and Receive activities 100

process flow

synchronous 20

public messages 8, 9

MSH error 26

SOAP envelop (see SOAP envelop) 162

structure 160

R

receipt reply pattern 39, 47

Rendeavous message format 73

require MSH receipt 40, 44, 48

require UsernameToken authentication of request 39,

47

resend log 112

resend log (see logs) 104, 104

resendable states 108

S

sequenced messages

poll interval 153

server URL 30

setting up the responder trading partner

properties 127

smart routing 155

SOAP envelop

MessageHeader 162, 166

states, transaction 109

status codes 82, 88, 91, 93, 96, 141

summary view 105

support, contacting xvii, xvii

synchronous reply modes 20

T

technical support xvii, xvii

TIBCO ActiveExchange 72, 73

TIBCO ActiveMatrix BusinessWorks 72

TIBCO ActiveMatrix BusinessWorks, configuring 99,

100

TIBCO_HOME xiv

timeout 40, 44, 48

trading host configuration 54

trading partner configuration 58

transaction

one-way pull 41

one-way push 36

two-way 44

transaction details view 105

transaction states 109

transports 31

in business agreement 68

in business agreements 68

in trading partner configuration 60

override 65

overriding 69

tutorial 113

overview 114

standalone private processes 113

two-way transaction 44

U

URL, server (see server URL) 30

tibco businessconnect ebxml protocol user s guide · pdf filetibco businessconnect ebxml...

Documents