Creating business-to-business connections between trading partners is a common use of BizTalk Server today. Establishing these connections requires agreement on the communication protocol that will be used, the formats of messages that will be exchanged, and the business process that drives the interaction. Managing trading partner relationships can get complex, especially when many organizations are involved or when the players change frequently.

To allow information workers to perform these tasks, Business Activity Services include a Trading Partner Management (TPM) component. This component relies on a TPM database, as shown above, that stores information about trading relationships. Using the common Business Activity Services interface, information workers can create and modify agreements with trading partners who use BizTalk Server 2006. Each agreement describes the relationship between two parties, and the things it contains include:

• A profile for each of the partners. Each profile contains business information about the organization, such as a contact person and address, along with technical information such as the protocol (which determines the BizTalk Server adapter) that should be used to communicate with them.
  
  
• The business process itself, implemented as one or more orchestrations, along with the role each of the partners plays. One organization might act as the seller, for example, while the other acts as the buyer.
  
  
• An addendum with parameters for the business process that control the behavior of the orchestration implementing it. How these parameters are used is described in the next section.
  
  

Profiles, agreements, and addendums are all stored in the TPM database. Using the TPM component (and for addendums, the Business Process Configuration component, described next), all of thedr can be configured directly by an information worker. This allows business people to establish and modify new partner relationships without relying on developers.

Although a business analyst may not be able to create the orchestration that implements a business process,it’s not unreasonable to expect an information worker to set parameters for that orchestration. An example of where this would be useful is when an orchestration will be used with multiple partners, but each partner requires slightly different behavior. Suppose, for instance, that the maximum dollar value of a purchase order is different with different trading partners, or perhaps the maximum quantity that can be requested varies depending on the customer’s credit rating. For this type of change, business analysts could make these small configuration changes themselves.

To enable information workers configure an orchestration, the developer creating it can define parameters for that orchestration. Information workers can then set these parameters as needed, perhaps assigning different values for different business partners or different parts of their own organizations. An information worker sets those parameters using the TPM service, described in the previous section, by specifying their values in the addendum to this partner’s agreement. For agreement that reference multiple orchestrations, an addendum can be created for each orchestration.