Understanding Routing Definitions
This section provides overview information about 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.
There are four routing types:
|
Field or Control |
Definition |
|---|---|
| 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. When working with synchronous service operations, you have the option to generate transactional routings, whereby the OnRequest event will run under the existing transaction boundary of the component. |
| Local-to-Atom |
A local-to-Atom routing is used exclusively with feeds functionality. See PeopleTools 8.55: Feeds Publishing Framework |
| Point-to-point |
A point-to-point routing requires that specific nodes that you define send and receive a transaction. |
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.
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.
User-Defined Routing Definitions
When you require a point-to-point routing, you must manually create it. 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.
Summary of Methods for Creating and Generating Routing Definitions
The following table summarizes the method for generating and defining routing definitions:
|
Routing Type |
System-Generated |
User-Defined |
|---|---|---|
|
Any-to-local |
Yes |
No |
|
Local-to-local |
Yes |
Yes |
|
Point-to-point |
No |
Yes |
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. |
|
System-generated at runtime. |
~GENERATED~<unique number> For example: ~GENERATED~15312 |
Routing definitions generated by the PeopleSoft system from the Service Operations-General tab. These routing definitions are any-to-local or local-to-local. |
|
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 using the Service Administration component. |
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.
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.
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.
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.