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 three routing types:

Any-to-local

An any-to-local routing enables the local node to receive transactions from any node.

This routing type is for inbound transactions only and the “any” node is always the sending node.

You can use this routing type for all service operation types, except for asynchronous-to-synchronous service operations.

Local-to-local

A local-to-local routing is a routing in which transactions are sent and received within the local database.

Point-to-point

A point-to-point routing requires that specific nodes that you define send and receive a transaction.

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 the three 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 created 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.

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

Routing Type

System-Generated

User-Defined

Introspection

Any-to-local

Yes

No

No

Local-to-local

Yes

Yes

No

Point-to-point

No

Yes

Yes

Routing Definition Naming Conventions

The following table lists the naming conventions for routing definitions:

Method for Generating and Creating Routing Definitions

Convention

Description

System-generated during upgrade.

~GEN_UPG~<unique number>

For example: ~GEN_UPG~10062

Routing definitions generated during the upgrade process. These may be any-to-local, local-to-local, or point-to-point routing
definitions.

Routing definitions generated or created by:

System-generated at runtime

Node introspection.

~GENERATED~<unique number>

For example: ~GENERATED~15312

Routing definitions generated by the PeopleSoft system from the Service Operations-General tab or from the Deployment Validation
component.

When generated from the Service Operations-General tab, these routing definitions are any-to-local or local-to-local.

When generated from the Deployment Validation component, routing definitions are usually point-to-point definition, but may
also be local-to-local routing definitions.

System generated by the Consume Web Service wizard.

~IMPORTED~<unique number>

For example:~IMPORTED~14857

Routing definitions generated using the Consume Web Service wizard.

User-defined.

Up to 30 characters, no spaces.

For example: QE_ROUTING.

No special characters, such as dots (“.”) and slashes (“/” or “\”), are permitted.

Manually created point-to-point routing definitions and local-to-local routings. You can also rename system-generated routing
definitions or introspected routing definitions using the Service Administration component.

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>.

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.

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.

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.

Viewing Routing Definitions

To view routing definitions defined for a service operation, use the Service Operations-Routings page.

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.

Page Used to Manage System-Generated Routing Definitions

Use this page to verify if any system-generated routing definitions exist for the service operation.

Use this page to initiate and regenerate system-generated any-to-local and local-to-local routing definitions.

Viewing System-Generated Routing Definition Status

The Service Operations-General page 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 or local-to-local 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.

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 page select PeopleTools, Integration Broker, Integration Setup, Service Operations.

The following example shows the Routing Actions Upon Save box:

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.

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

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.

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.

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.

The following example shows the Routing Actions Upon Save box when a routing definition can be regenerated:

To regenerate a system-generated routing definition:

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

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.

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.

Creating Routing Definitions

This section discusses how to:

Add a routing definition.

Define general routing definition information.

View routing parameters for requests and responses.

Override gateway and connector properties.

Understanding Creating Routing Definitions

This section provides an overview of routing definitions.

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.

Asynchronous service operations have the following routing parameters:

Service Operation Type

Sender is Local

Receiver is Local

Inbound Request Routing

Outbound Request Routing

Inbound Response Routing

Outbound Response Routing

Asynchronous One- Way

Y

Y

N

Y

N

N

Asynchronous One- Way

N

N

N

Y

N

N

Asynchronous One- Way

N

Y

Y

N

N

N

Asynchronous One- Way

N

N

Y

Y

N

N

Synchronous service operations have the following routing parameters:

Service Operation Type

Sender is Local

Receiver is Local

Inbound Request Routing

Outbound Request Routing

Inbound Response Routing

Outbound Response Routing

Synchronous

Y

Y

Y

Y

Y

Y

Synchronous

Y

N

N

Y

Y

N

Synchronous

N

Y

Y

N

N

Y

Synchronous

N

N

Y

Y

Y

Y

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

Service Operation Type

Sender is Local

Receiver is Local

Inbound Request Routing

Outbound Request Routing

Inbound Response Routing

Outbound Response Routing

Asynchronous-to-synchronous

Y

Y

Y

N

N

Y

Asynchronous-to-synchronous

Y

N

N

Y

Y

N

Asynchronous-to-synchronous

N

Y

Y

N

N

Y

Asynchronous-to-synchronous

N

N

Y

Y

Y

Y

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

Click the Routings tab. In the Routing Name field, add a name for a new routing definition and click the Add button.

Use the Routing Definitions page to add a routing record to the system. Also use this page to define or modify general information
about the routing, including the service operation (and version) for which the routing is defined, the sending node and the
receiving node. Use this tab to also activate and inactivate routing definitions.

Use the Parameters page to view routing parameters for individual transaction requests and responses associated with the service
operation. Information you can specify includes external aliases for requests and responses. Use this page to also specify
any transformations the system is to invoke on the inbound or outbound side of a transaction, as well as the message name
and version after transformation.

Use the Connectors page to override the default integration gateway and target connector that the local node uses for communicating
with an integration endpoint.

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

Adding Routing Definitions

You can add routing definitions to the PeopleSoft system from the Routings Definition page in the Routings component (IB_ROUTINGDEFN).
You can also add them from within a service operation record from the Service Operations-Routings tab.

Adding Routing Records 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:

Select PeopleTools, Integration Broker, Integration Setup, Routings.

Click the Add a Value tab.

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

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

The following graphic shows the page used when adding a routing definition from the Service Operations-Routing tab of a service
operation definition.

To add a routing definition from a service operation definition:

From within a service operation definition, click the Routings tab.

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

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.

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 show the Routing Definitions page used to define general routing information, as accessed from the Service
Operations-Routings page.

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.

Routing Name

Indicates the name of the routing definition. This name is specified when you add a routing definition to the system.

Service Operation

Enter the name of the service operation that will use the routing.

If you access the Routings component from the Service Operations-Routing tab, PeopleSoft Integration Broker automatically
populates this information.

Active

(Optional.) Check the box to activate the routing.

By default, new routing definition are active.

If any of the referenced nodes are inactive, you cannot activate the routing.

System Generated

When selected, indicates that the PeopleSoft system generated the routing definition.

Version

Indicates the version of the service operation selected.

Description

Description of the routing definition.

Comments

(Optional.) Enter comments about the routing definition.

Sender Node

Enter the name of the sending node.

Receiving Node

Enter the name of the receiving node.

Routing Type

Indicates the service operation type. PeopleSoft Integration Broker automatically populates this information when you select
the service operation.

User Exception

The User Exception check box displays only for synchronous service operations.

Check the box to enable exception handling using PeopleCode.

When enabled and an error occurs you can handle any errors in the calling PeopleCode.

If not enabled any errors that occur cause the program to stop.

Object Owner ID

(Optional.) From the dropdown list box, select the owner of the definition.

The owner ID helps to determine the application team that last made a change to the definition. The values in the dropdown
list box are translate table values that you can define in the OBJECTOWNERID field record.

Log Detail

The Log Detail dropdown list box displays only for synchronous service operations.

This option enables you to set the level of information logging for synchronous messages that is viewable in the Service Operations
Monitor.

The valid values are:

Header.

Log header information only. With this option, you can view synchronous message header information in the Service Operations
Monitor.

Header and Detail. Log header and message detail information. With this option, you can view synchronous message header information and XML
message content on in the Service Operations Monitor.

(Default.)

No Logging. (Default.) Turn off all logging. No information is available to view in the Service Operations Monitor.

OnSend Handler

This field displays when an OnSend handler is defined for the service operation and the sending node is the local node. It
also displays when you the system is serving as a hub, and neither the sender nor receiver are local.

Select a handler from the list. This handler runs when a message is sent or received to perform processing logic.

OnReceive Handler

This field displays when an OnReceive handler is defined for the service operation and:

The sending node is the local node.

The service operation type is asynchronous request/response where the sender is not local and the receiver is local.

The system is serving as a hub, and neither the sender nor receiver are local.

Select a handler from the list. This handler runs when a message is sent or received to perform processing logic.

Viewing Routing Parameters for Requests and Responses

Use the Routings-Parameters page to view 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. The following graphic shows the Routings-Parameter page:

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

Type

Specifies the routing direction and the type of message (request or response) associated with the service operation. This
information is automatically populated from the service operation definition.

External 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>.

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.

Duplicate external aliases are not allowed for synchronous operations.

Click the link to view other routing definitions with the same external alias.

Message.Ver info Transform 1

Displays the name of the request or response message associated with the service operation before any transformations are
applied.

For inbound transactions, this is the message name and version as it arrives from the integration partner system, before any
transformations are applied.

For outbound transactions, this is the message name and version directly from the PeopleSoft system, before any transformations
are applied.

Transform Program 1

(Optional.) Enter the name of the transform program to invoke on the message listed in the Message.Ver info Transform 1 field.

Transform Program 2

(Optional.) Enter the name of the transform program to invoke after the transform program in the Transform Program 1 field
has completed processing.

Note. When you invoke two transform programs, the output from the first transform program (Transform Program 1) is used as the input
into the second transform program (Transform Program 2).

Message.Ver out of Transforms

(Optional.) Enter the name of the message after all transform program have completed processing.

For inbound messages, this is the message name and version that the PeopleSoft system is expecting.

For outbound messages, this is the message name and version that the integration partner system is expecting.

Note. When the Routings-Parameters page first displays values for the Message.Ver info 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.

Overriding Gateway and Connector Properties

The Routings-Connector Properties page enables you to 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.

Gateway ID

Click the Lookup button to select an integration gateway.

Connector ID

Click the Lookup button to select a target connector that resides on the gateway entered in the Gateway ID field.

After you select a target connector, its required properties appear.

Save

Click the Save button to save your changes.

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.

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.

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.49 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:

Routing Definition On Local Node

Routing Definition on Introspected Node

Introspection Option

Inbound point-to-point routing.

None

Delete routing on local node.

Outbound point-to-point routing.

None

Delete routing on local node.

None.

Inbound point-to-point routing.

Create outbound point-to-point routing.

None.

Outbound point-to-point routing.

Create inbound point-to-point routing.

None.

Any-to-local routing. (Inbound.)

Create outbound point-to-point routing.

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.

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 in the Deployment Validation component (PTIB_INTROSPECTION) shown in
the following example to select service operations:

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:

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 dropdown list box, select the object owner of the service to provide.

Click the Search button.

A Select Operations grid appears that contains the search results.

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

To clear a selection, check the box again.

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 to select the nodes to introspect. The following example
shows this page:

To select a node to introspect:

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

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

Click the Search button.

A Select Nodes grid appears that contains the search results.

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.

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 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:

Service

The name of the service.

Service Operation

The name of the service operation

Default Version

The default version of the service operation

Action

Indicates the possible action to perform on the service operation. The valid values are:

None. Displays when a valid routing already exists between nodes. Also displays if there are no matching routing definitions on
sending and receiving nodes.

Delete Routing. Displays when there is a routing on the source node, but no corresponding routing on the target node.

Create Routing.. Displays when matching routing definitions are present on the sending and receiving nodes.

Direction

Indicates if the direction of the transaction is inbound or outbound. The valid values are:

Sending To. Indicates an outbound routing.

Receiving From. Indicates an inbound routing.

Blank. No routing found.

Node

Indicates the name of the node introspected.

Introspection Results

Indicates the results of the introspection. The valid values are:

A Routing exists locally. No routing found on the node. Delete local routing?. A routing definition exists on the local database, but there is no corresponding routing on the introspected node. You may
delete the routing definition on the local node.

No Match Found. Indicates that no matching routing was found on the introspected node.

Routing Created.The PeopleSoft system found a matching routing definition on the introspected node and created the routing.

Routing Deleted. The PeopleSoft system deleted the routing.

Any-to-Local routing found. Routing can be created. The target system has an any-to-local routing defined, meaning that it will accept transactions from any node. A routing
will be created.

Activating and Inactivating Routing Definitions in the Service Operations Component

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:

Select PeopleTools, Integration Broker, Integration Setup, Nodes.

Click the Routings tab.

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

The routing definition appears in the Routing Definitions page.

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.

Click the Save button.

Renaming and Deleting Routing Definitions

You can rename and delete routing definitions using the Routings tab in the Service Administration component. 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.

Deleting Duplicate Routing Definitions

The Service Administration - Routings page 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.

Page Used to Delete Duplicate Routing Definitions

Page Name

Object Name

Navigation

Usage

Service Administration-Routings page

IB_HOME_PAGE4

Select PeopleTools, Integration Broker, Service Utilities, Service Administration. Click the Routings tab. Click the arrow next to the Delete Duplicate Routings section title to expand the section.

Deleting Duplicate Routings

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

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.

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

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.