IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Key concepts
Relationships
A relationship is an association between two or more data entities, typically business objects. In IBM BPM Advanced, relationships can be used to transform data that is equivalent across business objects and other data but that is represented differently, or they can be used to draw associations across different objects found in different applications. They can be shared across applications, across solutions, and even across products.
The relationship service in IBM BPM Advanced provides the infrastructure and operations for managing relationships. Because it enables you to deal with business objects regardless of where they reside, it can provide a unified holistic view across all applications in an enterprise, and serve as a building block for BPM solutions. Because relationships are extensible and manageable, they can be used in complex integration solutions.
What are relationships?
A relationship is an association between business objects. Each business object in a relationship is called a participant in the relationship. Each participant in the relationship is distinguished from other participants based on the function, or role, it serves in that relationship. A relationship contains a list of roles.
The relationship definition describes each role and specifies how the roles are related. It also describes the overall "shape" of the relationship.
For example, this role can have only one participant, but this other role can have as many participants as necessary. You might define a car- owner relationship, for example, where one owner might own multiple cars.
For example, one instance could have the following participants for each of these roles:
- Car (Ferrari)
- Owner (John)
The relationship definition is a template for the relationship instance. The instance is the run-time instantiation of the relationship. In the car- owner example, an instance might describe any of the following associations:
- John owns Ferrari
- Sara owns Mazda
- Bob owns Ferrari
Using relationships frees you from the need to custom build relationship tracking persistence within your business logic. For certain scenarios, the relationship service does all the work for you. See the example described in the section on Identity relationships.
Scenarios
Here is a typical example of a situation in which an integration solution might use relationships. A large corporation buys multiple companies, or business units. Each business unit uses different software to monitor personnel and notebooks. The company needs a way to monitor its employees and their notebooks. It wants a solution that enables them to:
- View all the employees in the various business units as if they were in one database
- Have a single view of all their notebooks
- Allow employees to log on to the system and buy a notebook
- Accommodate the different enterprise application systems in the various business units
To accomplish this, the company needs a way to ensure, for example, that John Smith and John A. Smith in different applications are seen as the same employee. For Example, they need a way to consolidate a single entity across multiple application spaces.
More complex relationship scenarios involve building BPEL processes that draw relationships across different objects found in multiple applications. With complex relationship scenarios, the business objects reside in the integration solution, and not in the applications. The relationship service provides a platform for managing relationships persistently. Before the relationship service, you would have to build your own object persistence service. Two examples of complex relationship scenarios are:
- You have a car business object with a VIN number in an SAP application, and you want to track the fact that this car is owned by someone else. However, the ownership relationship is with someone in a PeopleSoft application. In this pattern of relationships, you have two solutions and you need to build a cross-bridge between them.
- A large retail company wants to be able to monitor merchandise returned for cash back or credit. There are two different applications involved: an order management system (OMS) for purchases, and a returns management system (RMS) for returns. The business objects reside in more than one application, and you need a way to show the relationships that exist between them.
Common usage patterns
The most common relationship patterns are equivalence patterns. These are based on cross-referencing, or correlation. There are two types of relationships that fit this pattern: non-identity and identity.
Non-identity relationships establish associations between business objects or other data on a one-to-many or many-to-many basis. For each relationship instance, there can be one or more instances of each participant. One type of non-identity relationship is a static lookup relationship. An example of this is a relationship in which CA in an SAP application is related to California in a Siebel application.
Identity relationships establish associations between business objects or other data on a one-to-one basis. For each relationship instance, there can be only one instance of each participant. Identity relationships capture cross-references between business objects that are semantically equivalent, but that are identified differently within different applications. Each participant in the relationship is associated with a business object that has a value (or combination of values) that uniquely identifies the object. Identity relationships typically transform the key attributes of business objects, such as ID numbers and product codes.
For example, if you have car business objects in SAP, PeopleSoft, and Siebel applications, and you want to build a solution that synchronizes them, you would normally need to introduce hand-built relationship synchronization logic in six maps:
- SAP -> generic
- generic -> SAP
- PeopleSoft-> generic
- generic-> PeopleSoft
- Siebel-> generic
- generic-> Siebel
However, if you use relationships in your solution, the relationship service provides prebuilt pattern implementations that maintains all these relationship instances for you.
Tools for working with relationships
The relationship editor in Integration Designer is the tool you use to model and design business integration relationships and roles. For detailed background and task information about creating relationships and using the relationship editor, see Create relationships.
The relationship service is an infrastructure service in IBM BPM that maintains relationships and roles in the system and provides operations for relationship and role management.
The relationship manager is the administrative interface for managing relationships. It is accessed through the Relationship Manager pages of the administrative console.
Relationships can be invoked programmatically through the relationship service APIs.
Overview
- Relationship service
- Relationship manager
- Relationships in ND environments
- Relationship service APIs
Related information:
Relationships
Relationship models
Identity relationships versus non-identity relationships
Static relationships
Create relationships