Genesis

Introduction to Trading Partner Integration

by Hussein Badakhchani

29/03/2005

Abstract

It is the goal of trading partner integration to streamline and automate the business processes that trading partners participate in an effort to reduce costs and create a strategic advantage. This article introduces the subject of Trading Partner Integration with BEA’s WebLogic Integration product to the reader. We will start by exploring the history of Trading Partner Integration (a.k.a. B2B integration) and defining what we mean by Trading Partner Integration, then we will examine the requirement for it as well as the challenges and benefits it brings to businesses. Following this we will identify the key concepts in Trading Partner Integration and finally we shall see how BEA’s WebLogic Integration product implements these ideas and simplifies the integration process.

Introduction

As enterprise Java developers coding business logic many of us would have faced the challenges posed by integrating trading partner services into our applications. Some of us turned to Web servicesfor the solutions. Those among us who have managed to find the time to do a little web surfing have probably noticed a few other terms and acronyms starting to find their way on to Java technology web sites, these include BPEL, ebXML, RosettaNet and WS-CDL. These specifications are all related in one way or another and it’s no coincidence that we are hearing more about them as between them they have the potential of making profound changes in the way approach trading partner integration. Take for example RosettaNet, a set of specifications (now arguably a standard) that allows trading partners to automate their supply chains. By creating a common “language” RosettaNet allows trading partners communicate supply chain movements with each other, orders, invoicing and payments, once manual processes that where time consuming and error prone can be streamlined into fast, secure and fault tolerant automated processes. Before we look at the benefits of Trading Partner Integration in more detail lets briefly look at its history.

A Brief history of trading partner integration.

Electronic Data Interchange (EDI) is widely considered as the first technology that gained major acceptance in the field of Trading Partner Integration. EDI technology has been around since the late sixties with the first implementation of an EDI compliant system emerging in 1970 by the Bankers Automated Clearing Service (BACS, now VOCA). It is a set of standardized electronic business documents that are exchanged in agreed-upon formats. EDI exploited the benefits of doing business and conducting transactions with your trading partners electronically and covered most things that were traditionally done using paper-based communication, but it wasn’t all plain sailing.

Early electronic interchanges used proprietary formats agreed upon between two trading partners requiring new programs each time a new partner was added to the existing system. Later on, some industry groups began a cooperative effort to develop industry EDI standards for purchasing, transportation, and financial applications. Many of these standards supported only intra-industry trading, which led to a large number of EDI formats. By the eighties EDI was an established technology among large corporations but high implementation and maintenance costs as well as a variety of competing standards hindered its widespread adoption among small and medium sized businesses. EDI remains at heart of many B2B integration efforts however, the arrival of Web services which enable real-time processing as opposed to the batch processing of traditional EDI applications and adherence to accepted open standards has made EDI a legacy technology in many organisations.

The advent of Web services, which we will define as using SOAP and WSDLto describe and access services over the network, re-ignited interest in trading partner integration by promising to deliver the benefits of integration more efficiently than previous initiatives. Among the key advantages offered by Web Services are:

• A simplified mechanism to connect an application regardless of the underlying technology or devices they use, or their location.
• Their are use of industry standard protocols and open standards.
• Universal vendor support.
• Their ability to leverage the internet for low cost communications, as well as other transport mechanisms.
• The loosely coupled messaging approach supports multiple connectivity and information sharing scenarios
  via services that are self describing and can be automatically discovered.
• Real time processing.
• Multiple levels of security.

The use of industry standard protocols and open standards deserves some elaboration as you can argue that without these Web services would suffer from the same restrictions of EDI. Vertical standards (industry specific standards) such as RosettaNet remove the burden of having to develop a new solution for each new trading partner that we wish to trade with and as these are built on horizontal standards (not specific to any sector or industry) such as BPEL and WS-CDL it facilitates integration across sectors for cross cutting concerns such as billing. A good example of this is the SWIFT message models already adopted by RosettaNet for corporate-to-bank payments and the work being done by TWIST to allow market participants to communicate with each other.

Trading partner integration by example.

To understand what we mean by Trading Partner Integration lets have a look at the relationships and business processes that may exist between trading partners in typical enterprise. At this point it is customary to provide an example based around an enterprise supply chain but we will break with tradition and look at an Automated Clearing House, ACH. Acme is a fictitious ACH that provides its customers, a collection of banks and large corporations, with a range of payment services. The core of Acme’s business is based around providing clearing services for direct debits and credits, the basic work flow of this process is as follows: Acmes customers submit details of direct debits and credits to Acmes payment services via submission files that are processed by batch daily. These files are in a proprietary format and are sent to Acmes payment service using HTTPS. Acmes payment services authenticate and submissions using internal processes and calls to third party OCSP (Online Certificate Status Protocol) responders. If any submissions fail the payment service informs both the customers and Customer Services; a separate department within Acme; of the failures. Acmes customers monitor progress of their transactions via hard copy reports which they receive from Acme through the post. Figure 1 shows the relationships and business processes between Acme and it’s trading partners.

[singlepic id=2 w=320 h=240 float=]

Figure 1. Relationships and business processes between Acme and it’s trading partners

Now that we understand some of Acmes business processes lets define what we mean by a trading partner. BEA’s WebLogic Integration documentation defines a trading partner as:

“An entity that has an agreement with another entity to participate in a specific business transaction, or service, by playing a predefined role associated
with a distinct business purpose. Trading partner applications form the nodes in system-to-system interactions among business partners.

To be clear its not referring to entity EJBs! To understand this definition lets apply it our example. The “entities” are: Acme Payment Services, Big Bank, Cheap Bank, Mega corp and the Customer services department. The services offered by the entities are payment service, report service and OCSP service. From Acme Payment Services department’s point of view its trading partners are the banks and corporations that use Acmes payment services, the OCSP responders that provide security checks and Acmes Customer Services department.

To quote again from the BEA documentation
A group of trading partners can:

• 
  Exist entirely within a company, spanning multiple corporate departments (the business purpose for such a
  community might be inventory management, for example).
  
• 
  Span multiple companies across firewalls and over the Internet (the business purpose might be supply chain
  management or multistep purchasing interactions, for example).
  
• 
  Include trading partners both within a company and in other companies (one or more of the trading partners
  within a company communicates with trading partners in other companies across the Internet)
  

At this point you may be wondering how WLI fits into the picture. To better understand how WLI may benefit Acme ACH manage the integration with its trading partners consider the following questions:

• Where do we store trading partners data, for instance contact information, services they provide, URLs to connect to etc?
• How do we make this information available to our existing applications and future applications.
• Trading partner data is sensitive, how can we keep it secure?
• How can we maintain and update this information?
• How can we monitor and gather usage statistics on the various services that we and our trading partner use?
• How to we manage the data pertaining to tens or hundreds of trading partners, and services they provide?

Many organisations do not address these questions fully or from an enterprise wide perspective. Solutions are typically add-hoc and scoped at department or even application level. This can lead to duplication of information, maintenance overheads and poor security. Most of us would have seen applications that store some trading partner information, say a web service URL in a properties file while another client of the service retrieves the same information from a database. WLI trading partner integration aims to address these questions in a consistent fashion.

Benefits and risks of trading partner integration

We mentioned earlier that one of the goals of trading partner integration is to provide a strategic advantage, how can Acme achieve this goal. Clearly, there is room for Acme to improve the services it provides to its trading partners. Acme recognises that the ability to allow trading partners (specifically the banks and corporate users of the payments service) to access their reports through a Web services interface; thereby allowing the trading partner to view reports on demand; would be of real benefit to its trading partners, helping them to streamline their business by removing all the inefficiencies associated with managing paper reports. Furthermore by providing a service that allows reports to be downloaded and stored in XML, trading partners will have the opportunity to integrate these reports with their organisation’s business management applications turning previously passive reports back into active commercial data giving them a significant strategic advantage.

The benefits that Acme is striving for are typical of the perceived benefits from trading partner integration which include:

• Reducing costs and improving efficiency by automating and streamlining manual processes.
• Enabling real-time management of your business processes and transactions.
• Improved security around business processes by providing encryption and non repudiation services.
• Creation of new strategic opportunities with trading partners.

All of this sounds great but as with any worth while endeavour there are associated risks. If we start by considering the group of trading partners that exist within a company Trading Partner integration can suffer from all the pitfalls of involved with Systems Integration and Interoperability. The typical strategies employed by systems integrators can be broadly categorized into three groups:

1. Shared data resources approach. Using this strategy different department information systems will communicate state changes over a shared resource
   such as database or file store. This approach can be fairly simple to implement and relatively cheap, however it may not scale well or be too
   too constrained to be a viable solution.
2. Employing Connector Architectures. In this case Enterprise Information Systems are connected to each other using “plug-in” connectors (also known as
   resource adapters or drivers) that comply with an adopted specification for example the “J2EE Connector Architecture”. One of the limitations of this approach
   is that a suitable “plug-in” connector may not exist for your EIS (although you could write your own). Maintaining a large number of “plug-ins” for your EISs
   or different versions of “plug-ins” can also prove to be a problem.
3. Synchronous/Asynchronous Messaging Architectures. Web services and standards based initiatives are making this method popular.

These approaches have benefits and trade-offs, selecting the right approach is a critical to the success of any integration effort and its the job of IT Architects to ensure the right decisions are made. When we consider integration with external trading partners the complexity of the task is further increased. The kinds of questions that need to be considered include:

• How well defined are the business processes that we engage with our trading partners?
• How do we manage trading partner data?
• What application protocols standards do we use?
• Do we build applications in-house or buy them off the shelf?
• Can we cope with multiple time zones, languages and cultures?

Lets see how we can use WebLogic Integration to answer some of these questions.

WebLogic Integration

The WebLogic Integration product aims to deliver some of the benefits of TPI that we have discussed, for instance we will see how using WLI you can automate and manage relationships with trading partners as well as streamline your business processes (with customers, suppliers, distributors, and other partners) and get a top-down view of business transactions across the value chain. Some of the features supported by WebLogic Integration include:

• Visual Public/Private Process Integration. By leveraging WebLogic Workshop, BEA’s IDE which is based on a unified programming model and run-time framework, business process integration can be easily implemented using controls and templates.
• Support for Leading Industry Protocols and Standards such as ebXML, RosettaNet and Web Services.
• Trading Partner Management (TPM) and Repository Access via the WebLogic Integration Administration Console, a web application which enables administrators to easily manage a central repository of trading partner profile information. We will consider the TPM in greater detail latter in this article.
• Easy Access to Run-Time Information.You can view run-time data and statistics using the WebLogic Integration Administration Console. The accompanying MBean API also facilitates real-time monitoring, process analysis, troubleshooting, and reporting for business messages.
• High Performance and Availability. WebLogic Integration supports clustered configurations for scalability and fail-over, message persistence for recovery, low-level acknowledgements and receipts, and transactional integrity.
• High Security, Auditing, and Non-Repudiation. WebLogic Integration ensures the private, secure, and reliable business message exchanges among trading partners using transport level security with SSL and message level security with digital signature and encryption. The certificates and private keys used for various purposes are kept in protected keystores while the passwords are kept in encrypted forms in the WebLogic Integration Password store.
• Trading Partner Enablement. WebLogic Integration works with WebLogic Integration – Business Connect, a lightweight B2B server that is designed for small trading partners who do not have their own B2B server. For trading partners who want a zero-install solution, WebLogic Integration can be easily extended to offer a browser or FTP interface.
• Third party support for EDI.

As you can see from this list, WLI provides the infrastructure that can be used to implement a TPI. Let’s now look at this in more detail.

Key Concepts

In order to understand how we can use WebLogic Integration for Trading Partner Integration we need to become familiar with some of key concepts it uses these can be surmised as:

• Trading Partner Management Repository.
• Trading Partner Profiles.
• Services.
• Service Profiles.
• Protocol Bindings.

Trading Partner Management (TPM) repository

The information pertaining to trading partner profiles, services, service profiles and protocol bindings reside in the TPM repository which is stored in a relational database, out of the box this will be a Pointbase database. All of this information as well as message tracking and trading partner activity can be managed via the WebLogic Integration Administration Console or by MBean APIs. WebLogic Integration also provide facilities to bulk load and transfer trading partner data. As BEA WebLogic Integration is built on BEA WebLogic Server we can use the WebLogic Console (not to be confused with the WebLogic Integration Administration Console) to identify the connection pool for the repository which is bpmArchPool. We can identify which tables store the trading partner data as they are helpfully prefixed “WLI_TPM” figure 2 shows the WLI_TPM_TRADING_PARTNER table. Examining the schema reveals other tables which store B2B configurations, process and work list data. In all the schema has some 188 tables.

[singlepic id=3 w=320 h=240 float=]

Figure 2. WLI_TPM_TRADING_PARTNER table

We will describe these bindings in the next section.

As we mentioned earlier one of the ways we can access and manipulate the data in the TPM repository is via the WebLogic Integration Administration Console, figure 3 shows us the view from the home page.

[singlepic id=4 w=320 h=240 float=]

Figure 3. The WLI Administration Console

For a complete guide to the WLI console see http://e-docs.bea.com/wli/docs81/manage/tpm.html.

Trading Partner Profiles

A trading partner profile includes the trading partner’s identifying information, and any certificates or protocol bindings required to conduct the business transactions. The following table describes some of these attributes in more detail.

Two test trading partners are provided by default, figure 4 shows Test trading partner 1 as viewed from the WLI Administration console. As we can see the from the console we can manage all these attributes, view Trading Partner Management Statistics which include message sent/received counts. We can also add custom extensions to the trading partner profile; these extensions are supplied as XML fragments.

[singlepic id=5 w=320 h=240 float=]

Figure 4. Test trading partner 1

These test trading partners are used in various WLI tutorials.

Services

Figure 5 depicts the Service Management page, the user is about to add a new RosettaNet service. A service typically represents a business process; a set of steps that, when executed, accomplish a certain business goal. Referring to our example, from figure 1, Acme ACH provides a payment and report services and consumes OCSP authentication services. Business processes are categorized as either public processes (involving interactions with trading partners, or private (internal to the organization). BEA’s documentation provides the following definitions:

• 
  Public processes are interface processes. Their definitions and designs are known, understood, and agreed upon by the organizations using them, and may be customized or standardized across an industry or industry segment, as in the case of RosettaNet Partner Interface Processes (PIPs). They are part of a formal contract between trading partners that specifies the content and semantics of message interchanges. These processes can be implemented in different ways by different trading partners. In the context of trading partner integration, when collaborative business processes are intended to be reused in multiple conversations with different trading partners, the business processes should be designed as public processes.
  
• 
  Participants in a conversation can also implement private, non-collaborative business processes, which can integrate their back-end processing. Private processes are the business processes conducted within an organization. Their definitions and designs are specific to that organization and are not visible outside it. Within trading partner enterprises, private processes interface with public processes and with back-end business systems. In the context of public processes, private processes can be thought of as sub-business processes or sub-processes that implement tasks that are part of the public business process. For example, a trading partner may implement a private business process that works in conjunction with a collaborative business process and that implements the processes that occur locally to a trading partner, but that are not necessarily dictated by the service agreement.
  

[singlepic id=6 w=320 h=240 float=]

Figure 5. Adding a new service

To better appreciate the benefits of using WLI TPI to manage services lets consider the payment service, if Acme ACH decided to support new open standards for submission files say using SWIFT and TWIST, Mega Corp would could start using these services without having to write new code to access the data required to establish secure connections, as we will see latter WLI provides ready made components that applications can use to access TPI data. Once Mega Corp update their repository with Acme’s new service data and certificates; either manually via the WebLogic Integration Administration Console or using the Bulk Loader with data provided by Acme ACH; they can concentrate on implementing the necessary business logic.

Service Profiles

Service profiles encapsulate the concept of an agreement between two trading partners on the service bindings to be used. Service profiles specify the protocol binding and URL endpoints for the local and remote trading partners that offer and call the service. An endpoint is a URL specifying the location of a message service that receives incoming messages. A service profile defines the interactions that two B2B trading partners agree to carry out, along with a specification for the business protocol implementation details such as messaging characteristics, security constraints, transport mechanisms, and workflow processes. Linking to the appropriate bindings for each trading partner specifies these characteristics. Each service profile is composed of a local trading partner with a single binding as well as a remote/external trading partner with its designated binding.

Protocol Bindings

Protocol bindings specify the business protocol used by the service, the current version of WLI supports ebXML 1.0, 2.0, RosettaNet 1.1, 2.0), and Web services. The transport protocol, for example HTTP 1.0, HTTP 1.1, or HTTPS 1.1; URL end-points, time-outs, number of retries, retry intervals, digital certificates, and other information pertaining to specifications of message delivery for the service.

What does this all mean?

We’ve gone from the theory about what TPI is to looking at the key concepts in WLI TPI. Let’s tie these two together now. In TPI, we need to be flexible in the way we communicate. One partner may be using RosettaNet, another ebXML indeed different services and even the same service (remember a service can have more than one profile) from a single trading partner can use different protocols, end points and security constraints. The repository is simply the internal structure used by WLI TPI to store the information necessary to describe each partner. In order to access the data in the repository, WLI provides a Trading Partner Management Control for use from within BEA Workshop. Based on POJOs, Controls are service-oriented components that make it easier to connect to and use any IT system or asset as a reusable service. The data can be maintained and updated using WebLogic Integration Administration Console or via the Bulk Loader utility. By centralising TPI data and providing easy access to it WLI TPI provides a standard way for all enterprise applications to retrieve the information they require to participate in transactions with trading partners.

Conclusion

In this article we have introduced the subject of Trading Partner Integration and explored the solutions provided by WebLogic Integration and WebLogic Workshop that help to manage your Trading Partner data and integrate it with our applications. In the next article in this series we will describe how to access the repository using the Trading Partner Management Control, data transformations and XQuery; delve into security issues around trading partner integration and learn about the process monitoring features that WLI has to offer.

Resources

• dev2dev – By developers for developers
• Introducing Trading Partner Integration
• Trading Partner Management
• The TPM Control
• The art of integration – Solution providers