Managing Service Operation Routing Definitions

This chapter discusses how to:

• Manage system-generated routing definitions.

• Add routing definitions.

• Configure routing definitions.

• Use introspection to create routing definitions.

• Activate and inactivate routing definitions.

• View routing definitions in graphical format.

• View integration status and activate integration metadata.

• Retrieve routing properties programmatically.

• Search for duplicate routing aliases.

• Rename and delete routing definitions.

• Delete duplicate routing definitions.

Understanding Routing Definitions

This section provides overview information about routing definitions.

Routing Definitions

A routing definition defines the sending and receiving nodes for a transaction, specifies any inbound and outbound transformations to invoke and defines external aliases. It also defines overrides that the default integration gateway and the default target connector that the local node use to communicate with an integration endpoint.

Routing Types

There are four routing types:

Defining Routing Definitions

A routing definition must exist on each system that is participating in a particular transaction.

For example, let's say that System A is going to send a service operation to System B and a point-to-point routing needs to be created between the two systems. Further, the local node on System A is called Node A, and the local node on System B is called Node B.

System A and System B need to have the identical service operation defined on each of their systems.

In addition, System A needs to have an outbound routing definition defined on its system that specifies its local node, Node A, as the sending node. The routing definition must specify System B's local node, Node B, as the receiving node.

System B needs to have an inbound routing definition defined on its system that specifies its local node, Node B, as the receiving node. The routing definition on System B also needs to specify System A's local node, Node A, as the sending node.

The exception to this is when a receiving system generates an any-to-local routing for a service operation. If the receiving system has an any-to-local routing definition defined for a particular service operation, it will accept requests from any node without the need of a specific point-to-point routing definition.

So using the examples of System A being the sending system and System B being the receiving system, this is what happens when an any-to-local routing is defined. System A still needs to have a routing definition defined on its system where its local node, Node A, is defined as the sending node, and System's B local node, Node B, is defined as the receiving node. On System B, when the any-to-local routing was generated, the PeopleSoft system automatically populated System B's local node, Node B, as the receiving node and listed the value of ~Any~ as the sending node to designate that the system will accept the service operation specified on the routing from any node.

Methods for Generating and Defining Routing Definitions

This section discusses methods of generating and defining routing definitions.

System-Generated Routing Definitions During Upgrade

If upgrading from a PeopleTools 8.47 or earlier release, during the upgrade process the PeopleSoft system creates routing definitions from node transaction and relationship data defined in your earlier PeopleTools 8.4x release.

System-Generated Routing Definitions During Consuming Services

When you consume a service using the Consume Web Service wizard, the system creates PeopleSoft integration metadata for the imported service, including routing definitions.

System-Generated Routing Definitions at Runtime

The PeopleSoft system can generate any-to-local and local-to-local routing definition for you. The system takes integration metadata from the service operation, including service operation name, service operation version, service operation type, local node information, and other data, and generates a routing definition.

If you make any subsequent modifications to the service operation, you can regenerate the routing definition to reflect the changes. In addition, at any point you can open the definition and manually modify it to include transformations, as well as override default integration gateway and target connector settings.

You use the Service Operations-General page to generate any-to-local and local-to-local routing definitions.

You may also manually create local-to-local routing definitions. However, you must always system-generate any-to-local routing definition.

See Managing System-Generated Routing Definitions.

User-Defined Routing Definitions

When you require a point-to-point routing, you may manually create the routing definition or generate it using introspection.

You can also manually create local-to-local routing definitions. However, you must always system generate any-to-local routing definitions.

To create user-defined routing definitions, use the Routings component or the Service Operations-Routings page.

See Adding Routing Definitions.

Introspecting Nodes To Generate Routing Definitions

PeopleSoft provides the ability to introspect other PeopleTools 8.52 nodes (PeopleSoft and external nodes) to generate point-to-point routing definitions.

You use the Deployment and Validation component to introspect nodes.

See Using Introspection to Create Routing Definitions.

Summary of Methods for Creating and Generating Routing Definitions

The following table summarizes the method for generating and defining routing definitions:

Routing Definition Naming Conventions

The following table lists the naming conventions for routing definitions:

Routing Definition External Aliases

When working with routing definitions you have the option of creating a routing alias. This alias is used as a SOAPAction attribute in the WSDL binding to identify the service operation in the Integration Broker metadata.

The routing external alias defaults to <ServiceOperationAlias>.<Version>, if present. Otherwise it defaults to <ServiceOperation>.<Version>.

In an asynchronous request/response any-to-local routing, the outbound routing alias format is <Alias Name>_CALLBACK.<Version>.

For inbound transactions you can fire multiple service operations for one invocation when external aliases on the routing definition are the same for each service operation. This is called service operation mapping.

See Also

Searching for Duplicate External Routing Aliases

Service Operation Mapping

Service Operation Mapping

You can map inbound asynchronous transactions to one or more service operations by specifying the name of the inbound transaction as the external alias on the routing for each service operation that you want to invoke.

Note. Service operation mapping is supported for inbound asynchronous transactions only.

For example, there is an inbound asynchronous transaction from SAP called Customer_SAP. However, the service operation contained in that transaction maps to two service operations on the PeopleSoft system, Customer_Get and Customer_Update. To invoke both service operations, change the external alias name on the inbound routing definition for the Customer_Get and Customer_Update service operations to Customer_SAP. When the routings are determined at runtime for this external service operation name, PeopleSoft Integration Broker will find both service operations (Customer_Get and Customer_Update) and process them accordingly.

Graphical Routings View

The Routing Definitions page provides a Graphical View link that enables you to view routing definitions in graphical format. The graphical routings view is intended to provide you with a view of the flow of data between integration partners.

See Also

Viewing Routing Definitions in Graphical Format

Integration Status

When you use the Graphical View link to view a routing definition in graphical format, an Integration Not Active link displays if any metadata associated with the integration is inactive. Inactive metadata might include the routing definition, the service operation, a service operation handler, and so on.

If you click the Integration Not Active link an Integration Status page appears and you can view activate the metadata.

Managing System-Generated Routing Definitions

This section discusses how to:

• View system-generated routing definition status.

• Initiate system-generated routing definitions.

• Regenerate system-generated routing definitions.

Understanding Managing System-Generated Routing Definitions

The PeopleSoft system can automatically generate any-to-local and local-to-local routing definitions when you save a service operation definition.

After the system generates the routing definition, you can view and fine-tune the definition as needed using the pages in the Routings component.

In addition, if you make any changes to a service operation after the system has generated a routing definition for it, you can have the system regenerate a routing definition. However, any modifications made to the routing definition are lost when you regenerate it.

Viewing System-Generated Routing Definition Status

The Service Operations-General page (IB_SERVICE) features a Routing Status box that you can use to verify if any system-generated routing definitions exist for a service operation. To access the page select PeopleTools, Integration Broker, Integration Setup, Service Operations.

The following example shows the Routing Status box:

When an any-to-local, local-to-local, or local-to Atom routing definition exists for the service operation, the corresponding field displays a status of Exists. When no routing definition exists, the corresponding field displays Does not exist.

Note. The system generates a Local-to-Atom routing definition when you publish a service operation as a feed. Using and managing feeds is described elsewhere in PeopleBooks.

See PeopleTools 8.52: Feeds Publishing Framework PeopleBook

Initiating System-Generated Routing Definitions

The Default Service Operation Version section of the Service Operations-General page features a Routing Actions Upon Save box where you can choose the type of routing to generate, any-to-local or local-to-local.

To access the Service Operations-General page select PeopleTools, Integration Broker, Integration Setup, Service Operations.

The following example shows the Routing Actions Upon Save box that appears when working with asynchronous service operation types:

The following example shows the Routing Actions Upon Save box that appears when working with a synchronous service operation type:

When you select Generate Local-to-Local, the Transactional box becomes available for selection. By choosing the Transactional check box, the system routes the service operations using the OnRequest event on a single transaction.

When you initiate system-generated any-to-local or local-to-local routings, PeopleSoft Integration Broker checks to see if the routing you are initiating is already in the system. This situation can arise when any-to-local and local-to-local routings are created in another database and are imported into the current database. If the routing already exists in the current database, a message appears indicating so and no new routing is generated. You must remove the routing before generating a new one.

See Deleting Duplicate Routing Definitions.

Note. Any-to-Local routing definitions are read-only, with the exception of the external alias name and transform information. You may need to change the external alias name for WSDL generation.

To initiate a system-generated routing definition:

1. From the Service Operations-General page, locate the Default Service Operation Version section.

2. In the Routing Actions Upon Save group box select one of the following options:

   • Generate Any-to-Local. Generates an any-to-local routing definition when you save the service operation record.

   • Generate Local-to-Local. Generates a local-to-local routing definition when you save the service operation.

     If working with a synchronous service operation, click the Transactional box if you want to generate a transactional local-to-local routing.

3. Click the Save button.

When you save the service operation the system generates the routing definition that you selected.

After you save the service operation definition the Routing Status group box displays a status of Exists for the routing definition generated.

To view the routing definition , click the Service Operations-Routings tab and click the name of the routing. The Routing Definitions page appears and you can view and modify routing definition details.

See Also

Routing Definition Naming Conventions

Defining General Routing Information

Defining Routing Parameters

Defining and Overriding Gateway and Connector Properties

Regenerating System-Generated Routing Definitions

If a system-generated routing exists for a service operation and you change some aspect of the service operation, you can have the system regenerate the routing definition. However, any modifications made to the routing definition are lost when you regenerate it.

To initiate the regeneration of a routing definition, use the Routing Actions Upon Save box on the Service Operations-General page to regenerate the routing. To access this page select PeopleTools, Integration Broker, Integration Setup, Service Operations.

To regenerate a system-generated routing definition:

1. Access the Service Operations-General page (PeopleTools, Integration Broker, Integration Setup, Service Operations).

2. On the page, locate the Default Service Operation Version section.

3. In the Routing Actions Upon Save group box select one of the following options:

   • Regenerate Any-to-Local. Regenerates an any-to-local routing definition when you save the service operation definition.

   • Regenerate Local-to-Local. Regenerates a local-to-local routing definition when you save the service operation.

4. Click the Save button.

When you save the service operation the system regenerates the routing definition that you selected.

After you save the service operation record the Routing Status group box displays a status of Exists for the routing definition generated.

Adding Routing Definitions

This section discusses how to:

• Add a routing definition.

• Define general routing definition information.

• Define routing parameters for requests and responses.

• Define routing properties.

• Define and override gateway and connector properties.

Understanding Adding Routing Definitions

The following table describes the location within the PeopleSoft system where you can add routing definitions to the system:

Note. When using the RSS feeds functionality you may need to create a routing definition for a non-default service operation version. The only location that you can add a routing definition for a non-default service operation version is in the Routings component.

Note. You cannot add routings to the system for REST-based services. You can only use system generated routings (any-to-local or local-to-local) for REST-based services.

Adding Routing Definitions Using the Routings Component

The following graphic shows the page used to add a routing record when using the Routings component:

To add a routing record using the Routings component:

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

2. Click the Add a Value tab.

3. In the Routing Name field, enter a name for the routing definition.

4. Click the Add button.

The routing definition is added to the system and the Routing Definitions page appears where you can define the routing details.

Adding Routing Definitions From Service Operation Definitions

When working in a service operation definition, you can use the Service Operations-Routing page (IB_SERVICERTNGS) to add a routing definition to the service operation. The following example shows the Service Operations-Routings page.

When you are adding a routing definition for a synchronous service operation, the system displays a User Exception box at the top of the page. Select the box to capture any exceptions that occur before the system validates an outbound routing for the service operation. This option enables you to capture errors such as inactive routing definitions, multiple routing definitions, any errors that result from running the OnRouteSend PeopleCode event, and other initialization errors. When the User Exception option is enabled and if an exception does occur before a routing can be validated, the system returns a response message to the integration partner that contains the exception.

To add a routing definition from a service operation definition:

1. Access the Service Operations - Routings page (PeopleTools, Integration Broker, Integration Setup, Service Operations. Click the Routings tab.)

2. (Optional.) Check the User Exception box to capture exceptions before routing validation.

3. In the Routing Name field, enter a name for the routing definition.

4. Click the Add button.

The routing definition is added to the system and the Routing Definitions page appears where you can define the routing details.

See Defining General Routing Information.

Adding Routing Definitions Using the Nodes Component

The following graphic shows the page used when adding a routing definition using the Nodes component.

To add a routing definition from the Nodes-Routings page:

1. Access the Nodes-Routings page (PeopleTools, Integration Broker, Integration Setup, Nodes. Click the Routings tab.)

2. In the Routing Name field, enter a name for the routing definition.

3. Click the Add button.

The routing definition is added to the system and the Routing Definitions page appears where you can define the routing details.

See Defining General Routing Information.

Configuring Routing Definitions

This section discusses how to:

• Define general routing information.

• Define routing parameters.

• Define and override gateway and connector properties.

• Define routing properties.

Defining General Routing Information

After you add a routing definition to the system use the pages of the Routing component to define the routing details. The following graphic shows the Routing Definitions page that you use to define general routing information, as accessed from the Service Operations-Routing Definitions page.

The fields that appear on the Routing–Routing Definitions page vary based on if you are defining a routing for a synchronous service operation or an asynchronous service operations.

The previous example show the Routing–Routings Definition page for a synchronous service operations. Fields such as Log Detail, User Exception, and OnSend Handler only appear on the page when you are working with a synchronous service operation.

The following example shows the same page for an asynchronous service operations:

The various ways to access this page are discussed in the previous section.

See Understanding Adding Routing Definitions.

When you add a routing definition from a service operation record, the PeopleSoft system automatically populates some of the data on this page based on the data in the service operations record from which you created the routing. Automatically populated data includes the service operation name, version, and routing type.

&MSG.IBInfo.CompressionOverride = %IntBroker_Compress;
Set/Get property for Compression override.  Valid parms : ⇒
%IntBroker_Compress, %IntBroker_UnCompress, %IntBroker_⇒
Compress_Reset

Defining Routing Parameters

This section provides an overview of defining transformations for any-to-local routing definitions and discusses how to define general routing parameters.

Understanding Routing Parameters for Requests and Responses

A routing definition contains routing parameters for each inbound request, inbound response, outbound request and outbound response associated with a service operation. The routing parameters that you can define include for each request or response include, routing alias, message names before and after transformation, and transformation program names.

You define routing parameters using the Routings-Parameters page in the Routings component.

The following tables list the number of routing parameters a routing definition contains based on the service operation type and whether the sending and receiving nodes are local.

Note. Parameters for routing definitions for REST service operations are not included in the following tables, since they are system generated.

Asynchronous service operations have the following routing parameters:

Synchronous service operations have the following routing parameters:

Asynchronous-to-synchronous service operations may have the following routing parameters:

Asynchronous request/response service operations may have the following routing parameters:

Understanding Transformations on Any-to-Local Routing Definitions

If you define a transformation on an any-to-local routing definition, the system uses the input message.version on the transform for the inbound request for WSDL. If a transform is defined on the outbound response, then the system uses the message.version on the output of the transformation for WSDL.

In cases where the input message.version or output message.version are not defined on the transform, the system uses the request or response message.version defined on the service operation for WSDL.

Note that any-to-local routing definitions are read-only when WSDL has been exported. As a result, you cannot change the in/out message transformation, aliases, and so on.

Defining Routing Parameters for Requests and Responses

Use the Routings-Parameters page (IB_ROUTINGDEFNDOC) to view and define parameters for requests and responses associated with a service operation. Information you define includes, routing external aliases for inbound and outbound requests and responses, as well as any inbound or outbound transformations to invoke.

To access the Routings - Parameters page, select PeopleTools, Integration Broker, Integration Setup, Routings and click the Parameters tab. The following graphic shows the Routings-Parameter page:

The following page elements display on the Routings-Parameters page:

When the Routings-Parameters page first displays values for the Message.Ver into Transform 1 and Message.Ver out of Transforms fields display values to assist you in choosing transform programs. After you save the page, values do not appear in these fields unless the transform programs have an input/output messages associated with them.

Note. Based on the transform selected, the message.version of the inbound request or response and the message.version of the outbound request or response that the system populated on the page can be different then those specified on the component. Should this occur a warning message displays and you can accept or reject the message.version information populated on the Routings - Parameters page. If you reject the message.version information populated on the page, you can modify the fields with the appropriate message.version information, or change the information that is specified on the component.

Defining and Overriding Gateway and Connector Properties

The Routings-Connector Properties page (IB_ROUTINGDEFCON) enables you to define and override the default integration gateway and target connector that the local node uses to communicate with an endpoint for a specific routing definition.

Note. The Routings-Connector Properties page displays in the Routings component only if the receiving node is not the local node.

The following graphic shows the Routings-Connector Properties pages used to define connector properties for a routing definition:

After you select an integration gateway and target connector with which to work, the system displays the required properties for the connector that you can set and override. To set or override additional properties add them to the properties list with the desired values.

The Routings-Connector Properties tab features the following controls:

Overriding Default Integration Gateways

To override the default integration gateway, use the Gateway ID field Lookup button to select a gateway. You must also select a target connector on the new gateway to use and define properties for that connector.

Overriding Default Target Connectors

To override the default target connector on the default integration gateway, use the Gateway ID field Lookup button to select the default gateway. Use the Connector ID field Lookup button to select a different target connector that resides on the gateway and then define properties for the new connector.

For REST-based services the connector ID default to HTTPTARGET and cannot be changed.

Overriding Default Connector Properties

To override the default target properties for the default target connector, use the Gateway ID field Lookup button to select the default gateway. Use the Connector ID field Lookup button to select the default target connector and then adjust the gateway properties as appropriate.

HTTP header properties, those with the property ID of HEADER, are the only properties you can add for routings for outbound REST-based service operations.

Defining Routing Properties

This section provides an overview of routing properties and discusses how to add them in the form of name/value pairs to routing definitions.

Understanding Routing Properties

Routing properties are user-defined name/value pairs that denote data contained in transformations defined for a routing definition.

Once they know the name/value pairs in a transformation, developers can extract the data from transformations using application classes. Developers might use the name/value pairs data to add to XML, perform SELECT actions in tables, and so on.

Defining Routing Property Name/Value Pairs

Use the Routings-Routing Properties page (IB_ROUTINGDEFNPROP) to add routing properties to a routing definition. The following example shows the Routings-Routing Properties page:

To add routing property name/value pairs:

1. Access the Routings-Routing Properties page (PeopleTools, Integration Broker, Integration Setup, Routings and click the Routing Properties tab).

2. From the Type drop-down list box, select a property type. The options are:

   • Category.

   • Ident.

   • Search.

3. In the Prop. Name field, enter a name for the property.

4. (Optional.) In the Value field, enter a value for the property.

5. (Optional.) In the Comment field, enter a comment or description for the name/value pair.

6. Click the plus button (+) to add additional rows and property name/value pairs.

7. Click the Save button.

Using Introspection to Create Routing Definitions

This section discusses how to:

• Select service operations for which to create routing definitions.

• Select the node to introspect.

• Select routing definitions to generate.

• View introspection results.

Understanding Using Introspection to Create Routing Definitions

You can introspect PeopleTools 8.52 nodes to create inbound or outbound point-to-point routing definitions on nodes that have matching service operations and versions for the local node. You can introspect PIA and External nodes types.

The following table lists the actions you can perform using introspection:

Prerequisites for Using Introspection to Create Routing Definitions

The following prerequisites exist for using introspection to create routing definitions:

• Nodes to be introspected must be active. To verify that a node is active, open the node definition for the node and make sure that the Active box is checked on the definition.

• External nodes to be introspected must have a WSIL URL defined on the node definition.

See Also

Configuring Nodes

Selecting Service Operations for Which to Create Routing Definitions

To begin using introspection to generate routing definitions, select the service operations for which to create routing definitions.

Use the Deployment Validation-Select Operations page (PTIB_INTROSPECT_0) in the Deployment Validation component (PTIB_INTROSPECTION) for this task. To access the page, select PeopleTools, Integration Broker, Web Services, Deployment Validation. The following example shows the Deployment Validation - Select Service Operations page:

You can search by service name and service operation. You can also search by object owner ID, if one is defined for the service. You can enter one or more of these criteria when performing your search. If you select no search options, the system searches for and returns all service operations in the database.

After you enter the search criteria and click the Search button, the results display in the Select Operations grid and you can select the service operations for which to generate routing definitions.

You can select one or more services operations for which to generate routing definitions.

To select services operations for which to generate routing definitions:

1. Select PeopleTools, Integration Broker, Web Services, Deployment Validation. The Deployment Validation-Select Operations page appears.

2. Enter search criteria for the services operations for which to generate routing definition. Provide one or more of the search criteria to narrow your search. Select no search criteria to retrieve a list of all service operations in the database.

   • In the Service field, enter a service name.

   • In the Service Operation field, enter a service operation name.

   • From the Object Owner ID drop-down list box, select the object owner of the service to provide.

3. Click the Search button.

   A Select Operations grid appears that contains the search results.

4. Check the box next to each service operation for which to generate a routing definition.

   To clear a selection, check the box again.

5. Click the Select Nodes button to proceed to select nodes to introspect.

Selecting Nodes to Introspect

Use the Introspection and Deployment Validation-Select Nodes page (PTIB_INTROSPECT_1) to select the nodes to introspect. The following example shows this page:

To select nodes to introspect:

1. Enter one or more of the following search criteria to search for a node:

   • In the Node Name field, enter a node name.

   • From the Node Type drop-down list box, select a node type. The options are:

     PIA	Designates the node as a PeopleSoft database that uses PeopleSoft Integration Broker.
     External	Designates the node as an entity that doesn’t use PeopleSoft Integration Broker.

     Note. The ICType node type displays in the list, however you cannot introspect the ICType node type to create routing definitions.

   • Select no search criteria to retrieve a list of all nodes defined in the database.

2. Click the Search button.

   A Select Nodes grid appears that contains the search results.

3. Check the box next to the nodes to introspect.

   If a node displays in the list, but isn't available for selection, the check box is grayed out. A node may not be available for selection due to not being active or in the case of external nodes, no WSIL URL is defined on the node definition.

4. Click the Introspect Selected Nodes button to introspect the node or nodes that you selected.

Click the Return to Service Operations link at any time to go back to the Deployment Validation-Select Operations page to modify the selection of service operations for which to generate routing definitions.

Selecting Routing Definitions to Generate

Use the Introspection and Deployment Validation-Introspection Results page (PTIB_INTROSPECT_2) to view the introspection results and select the routing definitions to generate.

After you introspect one or more nodes an Operation Results box displays for each service operation for which you are generating routing definitions. Select the actions to perform and click the Perform Selected Actions button.

The following page elements appear on the Introspection and Deployment Validation-Introspection Results page:

Viewing Introspection Results

After the system performs the selected actions, the following Introspection Results page (PTIB_INTROSPECT_2) appears:

The Introspection Results field shows the status for each routing definition.

You can view routing definitions created using the Routing Definition page or the Service Operations-Routings page.

See Also

Defining General Routing Information

Renaming Routing Definitions

Activating and Inactivating Routing Definitions

This section discusses how to:

• Use the Routings component to activate and inactivate routing definitions.

• Use the Service Operations component to activate and inactivate routing definitions.

• Use the Nodes component to activate and inactivate routing definitions.

Understanding Activating and Inactivating Routing Definitions

You can use the Routings component or the Service Operations component to activate and inactivate routing definitions.

Activating and Inactivating Routing Definitions in the Routing Component

You can use the Routings-Routing Definitions page to activate and inactivate a routing definition.

To activate or inactivate a routing definition:

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

   Select a routing definition with which to work.

2. Perform one of the following actions:

   • To activate the routing definition, check the Active check box.

   • To inactivate the routing definition, clear the Active check box.

3. Click the Save button.

Activating and Inactivating Routing Definitions in the Service Operations Component

You can also activate and inactivate routing definitions in the Service Operations component using the Service Operations-Routings page.

See Activating and Inactivating Routing Definitions.

Activating and Inactivating Routing Definitions in the Nodes Component

You can use the Nodes-Routings page to access a routing definition and to activate or inactivate a routing.

To activate or inactivate a routing definition from the Nodes component:

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

2. Click the Routings tab.

3. Locate the routing definition to activate or inactivate and click the Details link.

   The routing definition appears in the Routing Definitions page.

4. Perform one of the following actions:

   • To activate the routing definition, check the Active check box.

   • To inactivate the routing definition, clear the Active check box.

5. Click the Save button.

Viewing Routing Definitions in Graphical Format

This section discusses common elements used to view routing definitions in graphical format. It also discusses how to view routing definitions in graphical format.

Common Elements Used to View Routing Definitions in Graphical Format

Viewing a Routing Definition in Graphical Format

The Integration Broker Routing Graphic page (IB_IMAGETEST2), shown in the following example, displays routing definition data in graphical format:

The example shows that the service operation QE_PO_SYNC is associated with the routing. It also shows that the routing type is Synchronous.

The sending node is QE_LOCAL, and the node is depicted graphically by the cylinders on the left side of the example. The receiving node is QE_IBTGT and is depicted graphically by the cylinders on the right side of the example.

The example shows the outbound request from the node QE_LOCAL to the node QE_IBTGT has a routing alias of OUTBOUND_ROUTING_ALIAS.V1. It also shows that the outbound default message associated with the routing is QE_PO_MSG.VERSION_1.

When the node QE_IBTGT sends back its response, it has a routing alias of INBOUND_ROUTING_ALIAS.V1 and the message associated with the response is QE_PO_MSG.VERSION_1.

The dotted line depicts the integration gateway, and depending on the arrow direction shows the service operation leaving or entering the gateway.

Note in the example that an Integration Not Active link displays at the top right of the page. This indicates that one or more pieces of metadata associated with the integration is not active. Click the link to view and activate the data.

See Also

Viewing Integration Status and Activating Integration Metadata

Viewing Integration Status and Activating Integration Metadata

This section discusses how to:

• View inactive integration metadata.

• Activate integration metadata using the Integration Status page.

Understanding Viewing Integration Status and Activating Integration Metadata

When you view a routing definition in graphical format, if any metadata associated with the integration is inactive, an Integration Not Active link displays on the Integration Broker Routing Graphic page. You can click the link to open an Integration Status page, where you can view the inactive metadata and activate the data.

Note. The Integration Not Active link displays only when an integrations contains metadata that is not set to Active.

Viewing Inactive Integration Metadata

To view inactive metadata for an integration, from the Integration Broker Routing Graphic page, click the Integration Not Active link. The Integration Status page (IB_IMAGETEST_SEC), shown in the following example, displays:

The issues encountered box lists the metadata that is inactive and that you must activate before you can invoke the service operation.

The links in the Actions column enable you to activate the associated metadata directly from this page.

See Activating Integration Metadata Using the Integration Status Page.

Activating Integration Metadata Using the Integration Status Page

The system activates the associated metadata and displays a message when the data is successfully activated.

The following example shows the successful activation of a service operation from the Integration Status page.

To activate metadata for an integration using the Integration Status page:

1. From the Integration Broker Routing Graphic page, click the Integration Not Active link.

   The Integration Status page appears.

2. In the Actions column, click an action to complete.

   The system processes the action and displays a message that the metadata is activated.

3. Click the OK button.

4. Repeat the steps to activate additional metadata.

5. Click the Return button to go back to the Integration Broker Routing Graphic page.

Retrieving Routing Properties Programmatically

The %TransformData.routingDefnName property enables you to retrieve the routing definition name for a transaction, and allows you to retrieve the routing properties respectfully.

You use this property in a PeopleSoft Application Engine program as follows:

string rtgDefnName = %TransformData.routingDefnName

Searching for Duplicate External Routing Aliases

The Alias Name Reference page (IB_ALIASXREF_SEC) displays duplicate external routing aliases that exist for a routing definition.

To access the Alias Name Reference page, select PeopleTools, Integration Setup, Routings. Click the Parameters tab and click the Alias Reference link for a request or response. The following graphic shows the Alias Name Reference page:

The Alias Name Reference page appears only if the system finds that the external alias on the current definition also exists on one or more other routing definitions. If the system finds that the external alias is not used on any other routing definitions, it displays a message indicating so.

Note. The Alias Name Reference page appears only if a duplicate external alias exists on another routing definition.

Duplicate external routing alias names are never allowed for synchronous routing definitions and the system generates an error at runtime if it encounters any.

In most cases duplicate external routing alias names are not desired for asynchronous routing definitions. The exception is when you are using service operation mapping, and you want one routing definition to invoke multiple service operations.

To remedy the problem of duplicate external routing alias names, create unique alias names for each duplicate found.

To search for duplicate external routing alias names:

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

   The Routings Definition page appears.

2. Click the Parameters tab.

   The Parameters page appears.

3. Locate the request or response for which to check for duplicate external routing alias names.

   Click the Alias Reference link.

   If duplicate external routing alias names are found, the Alias Name Reference page appears and lists the routing definitions with which any duplicate aliases are associated. Otherwise, the system displays a message indicating that no duplicate aliases exist in the system.

Renaming and Deleting Routing Definitions

You can rename and delete routing definitions using the Routings page (IB_HOME_PAGE_4) in the Service Administration component (IB_HOME_PAGE).

The Routings tab contains three sections: a Delete section that enables you to delete routing definition, a Rename section that enables you to rename routing definitions, and a Delete Duplicate Routings section that enables you to view and delete duplicate routing definitions.

When you first access the Routings tab, the sections are collapsed. Click the section header arrow buttons to expand and collapse each section.

The following example shows the Routings tab with both Delete and Rename sections expanded:

The service system status that you set on the Services Configuration page affects the ability to rename services.

This section discusses renaming and deleting routings. See the following section for information about deleting duplicate routings.

See Understanding Configuring PeopleSoft Integration Broker for Handling Services, Using the Service Configuration Page to Set Service Configuration Properties, Deleting Duplicate Routing Definitions.

Renaming Routing Definitions

To rename a routing definition:

1. Select PeopleTools, Integration Broker, Service Utilities, Service Administration. Select the Routings tab.

   The Routing page appears.

2. Click the arrow next to the Rename section header to expand the section.

3. In the Routing Name field, enter the routing definition to rename, or click the Lookup button to search for and select one.

4. In the New Name field, enter the new name for the routing definition.

5. Click the Rename button.

After you click the Rename button, the Results field displays a message that the action was successful or displays a warning or error message with a description of the problem.

Deleting Routing Definitions

To delete a routing definition:

1. Select PeopleTools, Integration Broker, Service Utilities, Service Administration. Select the Routing tab.

   The Routing page appears.

2. Click the arrow next to the Delete section header to expand the section.

3. In the Routing Name field, enter the name of the routing definition to delete, and click the Search button.

   Search results display in the Routings grid.

4. Select the check box next to the routing definition or routing definitions to delete.

5. Click the Delete button.

Deleting Duplicate Routing Definitions

Application upgrades and the PeopleSoft Application Designer project copy process can cause duplicate routings in the PeopleSoft system.

The Service Administration - Routings page (IB_HOME_PAGE_4) features a Delete Duplicate Routings section that enables you to search for duplicate routings in the system and delete them. When you first access the page, all sections on the page are collapsed. Click the arrow next to the Delete Duplicate Routings section title to expand the section.

The following graphic shows the Service Administration–Routings page with the Delete Duplicate Routings section expanded:

The page displays active duplicate routings only.

To delete duplicate routings:

1. Select PeopleTools, Integration Broker, Service Utilities, Service Administration. Click the Routings tab.

   The Routings page appears.

2. Click the arrow next to the Delete Duplicate Routings section title to expand the section.

3. Click the Search button to search the system for duplicate routing definitions.

   Duplicate routing definitions populate the Routing Definitions grid and all duplicates are selected for deletion.

4. Clear the Select box for any routing definitions you do not want to delete.

5. Click the Delete button.

The Routing Definitions grid displays up to 100 routing definitions at a time. The maximum number of rows returned at a time is 1000. Use the arrow buttons to move from page to page through the search results. If the maximum number of rows is reached, an information message appears that indicates the maximum has been reached. After you delete the routing definitions, click the Search button again to return more rows.