Administering Relationships

This chapter discusses how to:

• Determine relationship parameters.

• Configure a relationship.

• Inactivate a relationship.

• Delete a relationship.

• Manage transaction modifiers.

Understanding Relationships

This section discusses when to use relationships and provides an overview of transaction modifiers.

Every integration requires at least one transaction at each PeopleSoft Integration Broker node. One node uses a transaction to send a message, and one or more nodes use transactions to receive the message. The sending node might apply a transaction with different parameters than those applied by the nodes that receive the message, with respect to routing, transmission type, message structure, or message content. A relationship reconciles incompatible parameters to successfully transmit data from the source to the target.

When to Use Relationships

You must define a relationship if any of the following is true:

• The source node sends a message asynchronously, but a target node expects to receive it synchronously.

• You’re using a hub configuration to route messages.

• One or more messages in a transaction needs to be filtered, transformed, or translated upon sending or receiving.

Relationships aren’t required for basic messaging if all of the following are true:

• Each node expects the message to have the same structure, version, and encoding as the other nodes.

• The transactions defined at each participating node all specify the same parameters (except transmission direction, which depends on a node’s point of reference).

• You’re not using a hub configuration (messages are sent directly from the source node to the target nodes).

Note. The relationship definitions you create, and the node definitions, transaction definitions, and transform programs they reference, are stored in the database you’re signed on to, which is the default local node.

See Also

Applying Filtering, Transformation and Translation

Integration Scenarios

Understanding Transaction Modifiers

A relationship applies a transaction modifier to an initial transaction, which produces a resulting transaction that’s appropriate for the target node. Only certain combinations of initial and resulting transaction types are supported, and both transactions must already be defined.

The following transaction type combinations are supported by PeopleSoft Integration Broker relationships.

Note. An outbound to inbound modifier would essentially define a local integration, in which the default local node is both source and target. However, unlike cross-node messaging, you need to define only one transaction for a local integration, and PeopleSoft Integration Broker automatically routes the message appropriately, so no transaction modifier is necessary.

See Also

Configuring Transactions

Applying Filtering, Transformation and Translation

Integration Scenarios

Determining Relationship Parameters

This section discusses how to:

• Select a transaction type combination.

• Determine where to define the relationship.

Selecting a Transaction Type Combination

The transaction type combination that you apply with a transaction modifier depends on the difference between what the source node sends and what the target node expects. The following scenarios can be handled using relationships:

• Different transmission types.

• Hub routing.

• Filtering, transformation, or translation.

The source or target node for any of these scenarios can itself be a hub. Each transaction modifier applies to a single segment of the journey a message makes from the initial source node to the ultimate target node. Additionally, any transaction modifier can invoke a transform program.

Different Transmission Types

In this scenario the source node sends an asynchronous request message, but the target node expects a synchronous message. Choose from the following solutions:

• The target node converts the inbound asynchronous message to synchronous using an InAsync to InSync modifier.

• The source node converts the outbound asynchronous message to synchronous before sending it using an OutAsync to OutSync modifier.

• A hub node receives the inbound asynchronous message and converts it to an outbound synchronous message using an InAsync to OutSync modifier.

Hub Routing

In this scenario you’re using the default local node as a PeopleSoft Integration Broker hub, and it receives an inbound request message. Choose from the following solutions:

• For an asynchronous message, the hub routes it to the target node using an InAsync to OutAsync modifier.

• For an asynchronous message, the hub converts it to an outbound synchronous message and routes it to the target node using an InAsync to OutSync modifier.

• For a synchronous message, the hub routes it to the target node using an InSync to OutSync modifier.

Note. No special setup is required to use a hub configuration. Any node where you apply an inbound to outbound transaction modifier is by definition a hub node. You can treat any PeopleSoft Integration Broker node simultaneously as a hub node and as a non-hub node for the same transaction.

See Retaining Messages at Hub Nodes.

Filtering, Transformation, or Translation

The target node expects a different request message or request message version than the source node sends, or the source node expects a different response message or response message version than the target node sends. Choose from the following solutions:

• The source node applies a transform program to the outbound asynchronous message using an OutAsync to OutAsync modifier.

• The source node applies a transform program to the outbound synchronous message using an OutSync to OutSync modifier.

• The target node applies a transform program to the inbound asynchronous message using an InAsync to InAsync modifier.

• The target node applies a transform program to the inbound synchronous message using an InSync to InSync modifier.

See Also

Applying Filtering, Transformation and Translation

Determining Where to Define the Relationship

You define a relationship at the node that will change the transmission type, apply the routing or invoke the transform program specified by a transaction modifier. Your choice depends on which node is best suited for the solution you need to apply.

If you need more than one type of solution, you might be able to combine them in a single relationship, or you might need to define separate relationships at different nodes. Consider which nodes you have control over, or whether you’re using a hub configuration.

The following example implements all three solution types with three different relationships:

1. At the initial source node, change the transmission type using an OutAsync to OutSync modifier.

2. At the hub, route the message using an InSync to OutSync modifier.

3. At the ultimate target node, transform the message using an InSync to InSync modifier.

The following example implements all three solution types with a single relationship:

At the source node, use a single OutAsync to OutSync modifier to change the transmission type, transform the message, and route the message directly to a different target node.

Note. Only one transaction modifier is applied to a given message at any node. Multiple transaction modifiers can’t be applied in sequence to a single message at a single node.

Configuring Relationships

A relationship applies a transaction modifier, which modifies the transmission type, destination, or message provided by the initial transaction, and uses the resulting transaction to pass the message on to its target. .

This section discusses how to:

• Define a relationship.

• Override node properties.

• Override contact information.

Understanding Configuring Relationships

To configure relationships, use the Relationships component (IB_RELATIONSHIP). To access the component, select PeopleTools, Integration Broker, Integration Setup, Relationships.

Defining Relationships

Select PeopleTools, Integration Broker, Integration Setup, Relationships.

Note that the Transactions Modifiers tab does not appear on until you create a relationship definition and save it.

Activating Relationships

When a relationship is active, PeopleSoft Integration Broker can invoke it to apply its transaction modifiers to qualifying transactions. However, the relevant message and node definitions in the local database must both be active as well. These elements have the following dependencies:

• When you deactivate a message, all associated relationships are deactivated.

• When you deactivate a node, all associated relationships are deactivated.

• You can specify only active nodes when defining a new relationship.

• You can activate any existing relationship without restriction.

Note. If you deactivate a node or a message, all relationships associated with it are also deactivated. Activating the node and the message won’t automatically reactivate the relationships; they must be individually reactivated.

Deactivating a relationship has no effect on the active status of other Integration Broker elements, but they do take it into account:

• If the integration engine invokes a transaction that’s associated with an inactive relationship definition, the relationship is ignored and the transaction runs as defined for its associated node.

• When you change the status of a relationship definition — either from active to inactive or from inactive to active — all elements of Integration Broker receive notification of the change in status, and the integration engine properly takes the relationship’s new status into account when invoking transactions and transaction modifiers associated with it.

See Also

Editing Transaction Modifier Details

Overriding Node Properties

Click the Properties link next to a node name on the Relationships page to access the Relationship Properties page.

Use this page to override the original properties of each node for this relationship. You can use these properties to update messages with additional information, such as adding a specific customer ID that’s needed by a trading partner when you send orders. Properties created for all relationships are stored in a single table, PSRELATIONPROP.

This page works the same way as the Node Definitions — Properties page.

See Defining Node Properties.

Note. These properties are saved as part of the relationship. Be sure to save the relationship after you edit this page.

Overriding Contact Information

Click the Contact link on the Relationships page to access the Relationship Contact page.

Use this page to override the original contact information of each node for this relationship. This page works the same way as the Node Definitions — Contact/Notes page.

See Specifying Contact Information.

Note. This contact information is saved as part of the relationship. Be sure to save the relationship after you edit this page.

Inactivating Relationships

To inactivate a relationship:

1. Select PeopleTools, Integration Broker, Integration Setup, Relationships.

2. Select the relationship to inactivate. The Nodes page appears.

3. From the Status drop-down list, select Inactive.

4. Click the Save button.

Deleting Relationships

You cannot delete relationships. As an alternative, you can inactivate a relationship and define a new one.

See Also

Inactivating Relationships

Defining Relationships

Managing Transaction Modifiers

This section discusses how to:

• View transaction modifiers.

• Define transaction modifiers.

• Edit transaction modifier details.

• Apply asynchronous to synchronous transaction modifiers.

• Retain messages hub nodes.

• Inactivate transaction modifiers.

• Delete transaction modifiers.

Viewing Transaction Modifiers

Select PeopleTools, Integration Broker, Integration Setup, Relationships, Transaction Modifiers to access the Relationships — Transaction Modifiers page. This page displays all transaction modifiers defined for the current relationship.

Edit	Click to access the Transaction Modifier Detail page and modify transaction modifier properties.
Add Transaction Modifier	Click to access the Relationship Transactions page and define a new transaction modifier.

Defining Transaction Modifiers

Click Add Transaction Modifier on the Trans Modifiers page to access the Relationship Transactions page.

Relationship ID	The ID for the current relationship is already entered, but you can select a different ID with which to associate this transaction modifier. Note. If you enter a different relationship ID than the current one, the selected relationship’s definition opens when you save the transaction modifier.
Initial Node and Result Node	Enter the name of the first or initial node that is sending or receiving the message.
Request Message Name	For both the initial and the resulting transaction, select the name of the request message each transaction should transmit. Note. Both request messages you select must be in the same channel.
Source Request Message Version	Enter the message version for the request message that the initial node sends or receives.
Transaction Type	For the initial transaction, select from: Outbound Asynchronous: The default local node sends a request message to the selected node. Outbound Asynchronous: The default local node sends a request message to the selected node. Outbound Synchronous: The default local node sends a request message to the selected node, requiring a response. Inbound Asynchronous: The default local node receives a request message from the selected node. Inbound Synchronous: The default local node receives a request message from the selected node, requiring a response.
Result Node	Enter the name of the result or second node that receives or sends a message to the initial node.
Target Request Message Version	Enter the message version for the request message that the result node sends or receives.
Add	Click to confirm the parameters you entered for the new transaction modifier and access the Transaction Modifier Detail page.

Only transactions included in the selected node definitions can be used by this relationship. As you select each parameter for a transaction (node, transaction type, request message name, request message version), the available choices for the remaining parameters are reduced to those that combine with your current choices to define existing transactions. For example, if you select a node with only inbound asynchronous transactions defined, Inbound Asynchronous is the only transaction type available.

Important! The integration engine should not be presented with two transaction modifiers that have initial transactions from the same node definition, specifying the same message and the same transaction type. The integration engine will attempt to apply both modifiers in parallel, producing two resulting transactions that send different results to the same target node. The effects of this situation are unpredictable, and it should be avoided.

Make sure you don't select the same initial transaction for any two transaction modifiers in the same relationship. Also, if you select the same initial transaction for two transaction modifiers in different relationships, make sure the result transaction doesn't target the same node in both modifiers.

Connector Overrides in Transaction Modifiers

When you define a transaction modifier, be aware of the way it handles connector overrides specified by the transactions involved. In some cases, the modifier ignores all connector overrides and uses the connector and its properties specified by the node associated with the result transaction.

A connector override is applied in a transaction modifier only if both of the following are true:

• The connector override is specified by the result transaction.

• A connector override is not specified by the initial transaction.

Note. This behavior must be taken into account if you use a transaction both in basic integrations and in a transaction modifier, because the connector override is applied with the basic integration, but might not be applied in the transaction modifier.

For example:

1. Define node X containing transaction X. The node specifies connector A, so the transaction uses connector A for basic integrations.

2. Define node Y containing transaction Y. The node specifies connector B, so the transaction uses connector B for basic integrations.

3. Define a transaction modifier with initial transaction X and result transaction Y. The modifier will use connector B. However:

   • If you don’t specify a connector override for initial transaction X, but specify connector O as an override for result transaction Y, the modifier will use connector O.

   • If you specify any connector override for initial transaction X, the modifier reverts to connector B, no matter what you’ve specified for result transaction Y.

Note. A connector override doesn’t need to specify a different connector than the one specified by the node; it might just apply different properties for the same connector. The behavior described here applies to any type of connector override setting.

See Also

Configuring Transactions

Editing Transaction Modifier Details

Click Edit on the Transaction Modifiers page to access the Transaction Modifier Detail page. You can also click Add on the Relationship Transactions page.

Note. The transaction modifier’s basic parameters are read-only, and can be altered only by defining a new transaction modifier with different values. The Async Reply Message and Async Reply Message Version fields appear only if you selected an asynchronous initial transaction and a synchronous resulting transaction.

When PeopleSoft Integration Broker invokes a transaction whose parameters match those of the initial transaction specified in this transaction modifier, the transaction modifier is applied to produce and invoke the specified resulting transaction. A given transaction modifier is applied only if both it and its parent relationship are active.

Activating Transaction Modifiers

Transaction modifiers are dependent on their parent relationships in the following ways:

• When you deactivate a relationship, all associated transaction modifiers are deactivated.

• You can create new transaction modifiers for inactive transactions, but they can be saved only with inactive status.

Note. Activating the relationship or both transactions won’t automatically reactivate the associated transaction modifiers; they must be individually reactivated.

Applying Asynchronous-to-Synchronous Modifiers

When you apply an asynchronous to synchronous transaction modifier, the request message is received by the target node in synchronous mode, so that node sends a synchronous response. The only way the source node can accept a response message is in asynchronous mode, so the transaction modifier converts the synchronous response into an asynchronous request and sends it to the source node as an independent asynchronous transaction in reply to the original transaction. You specify this request with the Async Reply Message and Async Reply Message Version fields on the Transaction Modifier Detail page.

Note. The message you specify must have the same structure as the response message sent by the target node, and both must be in the same channel as the initial request message.

You can define and apply the transaction modifier at either the source node or the target node. Because the asynchronous response message is technically unrelated to the initial asynchronous request, you must define appropriate transactions at both the source and target nodes to accommodate it. The following examples describe the transactions required for an exchange in which node A sends message X to node B and receives message Y in response.

Applying Transaction Modifiers at Source Nodes

In the node A database, an OutAsync to OutSync modifier specifying asynchronous “response” message MSG_Y (really just another request) is defined as part of the NODE_B to NODE_B relationship. To apply the modifier, you must have defined the transactions described in the following table.

Applying Transaction Modifier at Target Nodes

In the node B database, an InAsync to InSync modifier specifying asynchronous “response” message MSG_Y (really just another request) is defined as part of the NODE_A to NODE_A relationship. To apply the modifier, you must have defined the transactions described in the following table.

Retaining Messages at Hub Nodes

If you’re using an inbound to outbound transaction modifier for message routing at a hub node, you may want the hub node to retain (receive and process) the message locally as well. You define an additional transaction modifier to accomplish this. The following example specifies the transactions required for an exchange in which source node A sends message X to hub node B, which routes the message to target node C and retains the message itself as well.

Applying Basic Routing

In the node B database, an InAsync to OutAsync modifier is defined as part of the NODE_A to NODE_C relationship. To apply the modifier, you must have defined the transactions described in the following table.

Retaining Messages

For node B to receive and process the same message, the appropriate InAsync transaction is already defined in the node B database, as shown in the table. Additionally, the node B database must contain a NODE_A to NODE_A relationship which includes an InAsync to InAsync modifier. The modifier essentially routes the message back through the original transaction, at which point node B can receive and process it normally.

Note. PeopleSoft Integration Broker doesn’t support applying multiple transaction modifiers in sequence to a single message. However, you can apply them in parallel, as in this example.

Inactivating Transaction Modifiers

To inactivate a transaction modifier:

1. Select PeopleTools, Integration Broker, Integration Setup, Relationships.

2. Select the relationship that contains the transaction modifier to inactivate. The Nodes page appears.

3. Click the Trans Modifier tab.

4. In the Transaction Modifiers section, click the Edit link of the transaction with which to work.

5. From the Status drop-down list, select Inactive.

6. Click the Save button.

Deleting Transaction Modifiers

You cannot delete transaction modifiers. As an alternative, you can inactivate a transaction modifier and then define a new one.

See Also

Defining Transaction Modifiers

Inactivating Transaction Modifiers