Tuning Messaging System Performance

This chapter discusses how to:

• Throttle dispatched messages through the messaging system.

• Use multi-threading to send groups of service operations in parallel.

• Send and receive large segmented messages using parallel processing.

• Implement exception handling for synchronous message processing.

• Implement master-slave dispatchers.

• Allow multiple active domains.

• Set up domain failover

• Configure integration gateways for load balancing when using third-party software.

• Implement load balancing on service operation queues.

• Implement load balancing using virtual application server domains.

• Resubmit failed transactions.

• Use the bulk load handler for large message subscriptions.

• Manage pub/sub process handler performance.

• Use Web Service Reliable Messaging.

Understanding Tuning Messaging System Performance

This chapter discusses actions you can take to tune messaging system performance.

In addition, you can view messaging system performance statistics using the Service Operations Monitor.

See Also

Viewing System Performance Statistics

Throttling Dispatched Messages Through the Messaging System

You can throttle the number of dispatched messages from a given dispatcher to its associated handler(s).

Throttling the messages that pass through the messaging system enables you to avoid Tuxedo queue saturation due to redundant Tuxedo calls, which result in degraded performance.

You can throttle messages on any of the three pub/sub dispatchers:

• PSBRKDSP

• PSPUBDSP

• PSSUBDSP

To set up dispatcher throttling, you must set the following parameters located in PSAdmin:

• Tuxedo Queue Status Check Count

• Dispatcher List Multiplier

• Dispatcher Queue Max Queue Size

Information for setting these parameters is described earlier in this PeopleBook.

See Specifying Dispatcher Parameters.

Using Multi-Threading to Send Groups of Messages in Parallel

This section provides an overview of multi-threading and discusses how to:

• Specify the number of available threads.

• Implement multi-threading.

Understanding Multi-Threading

Multi-threading allows you to send a group of synchronous requests in parallel, thereby eliminating the need to wait for a response for one synchronous message to be returned before you send the next synchronous message. You can also use multi-threading to send a configurable number of asynchronous message publications in parallel.

Multi-threading enables you to pool request messages into an array and make a threaded call.

When working with synchronous messages, responses are returned in an array, and are pooled in the same order in which you send them.

Multi-threading supports sender-specified routing, thereby enabling you to pass in an array of nodes on the SyncRequest call.

See Also

Implementing Exception Handling for Synchronous Message Processing

Specifying the Number of Available Threads

The number of threads available determines the number of message you can send in parallel. For example, if there are 10 threads available, you can send 10 messages in parallel.

To specify the number of threads available for multi-threading set the Thread Pool Size parameter in PSAdmin.

The thread pool size only affects the number of messages processed at the same time, and does not limit the number of messages you can send in one API call.

Setting the Thread Pool Size for Synchronous Messaging

For synchronous messaging, set the Thread Pool Size parameter in the General Settings for Integration Broker section in PSAdmin.

For synchronous messaging, The default value is 5. The minimum value is 1 and the maximum value is 20.

Setting the Thread Pool Size for Asynchronous Messaging

For asynchronous messaging, set the Thread Pool Size parameter in the Settings for Publication Contract Handler section in PSAdmin.

For asynchronous messaging, The default value is 1. The minimum value is 1 and the maximum value is 20.

Implementing Multi-Threading

This section provides the syntax for multi-threading and provides a synchronous multi-threading code example.

Syntax

The syntax for implementing multi-threading is:

Array of messages = %IntBroker.SyncRequest(Array of messages, array of 
sender-specified routing);

The IntBroker object is responsible for managing the messages, instantiation of the SyncRequest handler and calling the Send method for each request. The IntBroker object then polls the SyncRequest handler object to determine when all processing is complete. At that time, status and error checking is performed and the response message objects are created. The response messages are packaged as an array and returned to the calling method.

Synchronous Multi-Threading Example

The following example shows code for synchronous multi-threading

Local Rowset &FLIGHTPLAN, &FLIGHTPLAN_RETURN;
Local Message &MSG;

Local array of Message &messages;
Local array of Message &return_mesages;

&messages = CreateArrayRept(&MSG, 2);
&return_mesages = CreateArrayRept(&MSG, 2);

&FLIGHT_PROFILE = GetLevel0();
&messages [1] = CreateMessage(Message.QE_FLIGHTPLAN_SYNC);
// populate the rowset
&messages [1].CopyRowset(&FLIGHT_PROFILE);

&messages [2] = CreateMessage(Message.QE_FLIGHTPLAN_SYNC);
// populate the rowset
&messages [2].CopyRowsetDelta(&FLIGHT_PROFILE);

&return_mesages = %IntBroker.SyncRequest(&messages);

// process the return rowset
&FLIGHTPLAN_RETURN = &return_mesages [1].GetRowset();
&temp = &return_mesages [1].GenXMLString();

// process the return rowset
&FLIGHTPLAN_RETURN = &return_mesages [2].GetRowset();
&temp = &return_mesages [2].GenXMLString();

See Also

SyncRequest

Sending and Receiving Large Segmented Messages Using Parallel Processing

This section discusses how to:

• Use the OnPreNotify and OnPostNotify PeopleCode events.

• Using the bulk load handler to process large message segments in parallel.

• Select the unordered segments option on the Routings-Routings Definition page.

• Assign service operations to long-running event queues.

Understanding Sending and Receiving Large Segmented Messages Using Parallel Processing

Using parallel processing to send and receive asynchronous service operations that contain large message segments increases integration through-put time.

In sequential processing service operations are processed in order, where the processing of one message must complete before the next message in the queue is processed. In parallel processing, messages are processed in unordered queues, as resources are available for processing.

You can improve system performance and processing times by performing any of these actions.

• Use the OnPreNotify and OnPostNotify PeopleCode events.

• Use the Bulk Load Handler.

• Select the Unordered Segments option on the Routings–Routing Definition page.

• Load balance these types of service operations using long-running event queues.

The only option you must set to send and receive segmented messages using parallel processing is the Unordered Segments option on the Routings–Routing Definitions page. The other options discussed in this section enhance the processing of these types of service operations.

Using the OnPreNotify and OnPostNotify PeopleCode Events

The OnPreNotify and OnPostNotify service operation handler events enable you to perform pre- and post-processing actions on a service operation.

Use the OnPreNotify event to perform high-level pre-processing on data. Typically, this event is used to truncate the database table(s) if a destructive load, versus an update, is required. Note that you cannot use this event to modify actual message data.

Use the OnPostNotify event to perform actions such as start an application engine program, send an email message to indicate the transaction has been completed, and so on.

When implemented, the Broker handler first processes the OnPreNotify PeopleCode event. Then, the system creates one subscription contract for each message segment. The system processes the subscription contracts in parallel, except for the OnPostNotify contract. The OnPostNotify contract runs only after all subscription contract(s) are completed .

Using the Bulk Load Handler to Process Large Message Segments in Parallel

Using the bulk load handler is a good option when you are processing large messages and large message segments.

The Bulk Load Handler page (IB_SERVICEHDL5_SEC) used to configure a bulk load handler has a field called Truncate Table(s) that provides the option to truncate or not truncate tables. When using the OnPreNotify or OnPostNotify events, clear the Truncate Table(s) option so that tables are not truncated.

See Also

Enabling Table Truncation

Selecting the Unordered Segments Option on the Routings-Routings Definition Page

The Routings-Routings Definition page (IB_ROUTINGDEFN) features an Unordered Segments option. The option appears only when working with an inbound routing definition for an asynchronous service operation. The following example shows the Routings-Routing Definition page for an inbound routing definition, and shows the Unordered Segments option:

When you select the Unordered Segments option for an inbound routing definition, the system creates a subscription contract for each segment and processes the contracts in parallel.

Assigning Service Operation that Contain Large Segmented Messages to Long-Running Event Queues

For better performance and through-put times, you can load balance the processing of service operations that contain large segmented messages by assigning them to long-running event queues.

Implementing master-slave load balancing by using long-running event queues is described elsewhere in this PeopleBook.

See Setting Up Master-Slave Load Balancing for Long-Running Events.

Implementing Exception Handling for Synchronous Message Processing

When a an outbound synchronous request fails you can throw a framework exception leading to a message box error and subsequent component roll back of the transaction.

Note. This type of exception handling applies to outbound synchronous requests only, including outbound multi-threaded synchronous requests.

For example, if 10 synchronous requests are performed in parallel (threaded sync request), you have the option to select the User Exception check box on the routing definition for the service operation. When the User Exception check box is selected, if any of the synchronous requests error, the component is not rolled back. You can check each synchronous request to determine if there is an error and actually read the associated error message. You can then throw an exception or go on to process the next synchronous request in the array.

See Managing Service Operation Routing Definitions.

The following example shows sample pseudo PeopleCode to read the exception:

Local Rowset &FLIGHTPLAN, &FLIGHTPLAN_RETURN;
Local array of Message &messages;
Local array of Message &return_mesages;

&messages = CreateArrayRept(&MSG, 2);
&return_mesages = CreateArrayRept(&MSG, 2);

QE_FLIGHTDATA.QE_ACNUMBER.Value = QE_FLIGHTDATA.QE_ACNUMBER + 1;

&FLIGHT_PROFILE = GetLevel0();

&rs1 = &FLIGHT_PROFILE.GetRow(1).GetRowset(Scroll.QE_NAVIGATION);
&rs2 = &FLIGHT_PROFILE.GetRow(1).GetRowset(Scroll.QE_RADAR_PRESET);
&rs3 = &FLIGHT_PROFILE.GetRow(1).GetRowset(Scroll.QE_ARMAMENT);
&messages [1] = CreateMessage(Operation.SYNC_PARTS);

For &i = 1 To &messages [1].PartCount
   
   If &i = 1 Then
      &rs1.CopyTO(&messages [1].GetPartRowset(&i));      
   End-If;
   
   If &i = 2 Then
      &rs2.CopyTO(&messages [1].GetPartRowset(&i));    
   End-If;
   
   If &i = 3 Then
      &rs3.CopyTO(&messages [1].GetPartRowset(&i));
   End-If;
   
End-For;

&messages [2] = CreateMessage(Operation.SYNC_PARTS);

For &i = 1 To &messages [2].PartCount
   
   If &i = 1 Then
      &rs1.CopyTO(&messages [2].GetPartRowset(&i));
   End-If;
   
   If &i = 2 Then
      &rs3.CopyTO(&messages [2].GetPartRowset(&i));
   End-If;
   
   If &i = 3 Then
      &rs2.CopyTO(&messages [2].GetPartRowset(&i));
   End-If;
   
End-For;

&return_mesages = %IntBroker.SyncRequest(&messages);

If &return_mesages [1].ResponseStatus = %IB_Status_Success Then
   
   For &i = 1 To &return_mesages [1].PartCount
      
//perform local processing on response data

   End-For;
   
Else
   
   &nMsgNumber = &return_mesages [1].IBException.MessageNumber;
   &nMsgSetNumber = &return_mesages [1].IBException.MessageSetNumber;
  &exceptString = &return_mesages [1].IBException.ToString();
// Evaluate exception and throw error if necessary
   
End-If;

If &return_mesages [2].ResponseStatus = %IB_Status_Success Then
   
   For &i = 1 To &return_mesages [2].PartCount
      
  //perform local processing on response data   End-For;
   
  Else
   
   &nMsgNumber = &return_mesages [2].IBException.MessageNumber;
   &nMsgSetNumber &return_mesages [2].IBException.MessageSetNumber;
  &exceptString = &return_mesages [2].IBException.ToString();

// Evaluate exception and throw error if necessary
   
End-If;

Implementing Master-Slave Dispatchers

This section provides an overview of master-slave dispatching and describes how to:

• Configure dynamic slave dispatchers.

• Configure static slave dispatchers.

• Create template slave domains.

• Implement master-slave load balancing.

• Implement deferred master domain processing.

Understanding Implementing Master-Slave Dispatchers

Master-slave dispatching is where a master domain allocates messages to one or more slave dispatchers for processing. This section provides an overview of master-slave dispatcher processing.

Master-Slave Dispatcher Processing

A slave dispatcher processes service operations assigned to it by a master dispatcher.

A master domain allocates service operations to a slave for processing when:

• The master detects that a slave dispatcher is active and not busy processing service operations.

• The slave has an active queue on which the master is currently processing service operations.

The dispatcher(s) processing in slave mode then process the allocated service operations.

Master and slave dispatchers can reside on the same or on different machines.

Note. When master-slave processing is implemented, there can be only one master domain at a given time.

You can create a domain consisting of only dedicated slave pub/sub servers. These servers register themselves as slaves, along with additional configurable information, such as the number of process handlers booted, so that the appropriate master server can use that information to allocate work (service operations to process) to the slave server(s).

The master domain can allocate work to one or more slave domains.

Slave Types

There are two types of dispatcher slaves:

Failover and Master-Slave Dispatchers

You can create a slave domain for use in domain failover.

The domain with the highest priority dynamically becomes the active domain (master domain) in each group during failover. The next domain in priority will be programmatically configured as an active slave domain.

When a failover occurs the domain that failed becomes inactive. The failover domain specified goes from an active slave to an active master. The next domain in priority then becomes an active slave.

You can set failover for slave dispatchers. However, slave dispatchers cannot be part of any group and you cannot prioritize them.

See Setting Up Domain Failover.

Configuring Dynamic Slave Dispatchers

Use the Failover Configuration page in the Service Operations Monitor to configure dynamic slave dispatchers.

See Setting Up Domain Failover.

Configuring Static Slave Dispatchers

You use PSAdmin to specify a pub/sub dispatcher as master or slave by setting the following property:

See Also

Using the PSADMIN Utility

Creating Template Slave Domains

This section discusses how to:

• Import domain configurations from application domains.

• Import domain configurations from files.

• View template slave domains

• Add and delete dispatcher queues from template slave domains.

• Restore dispatcher queue lists.

Understanding Template Slave Domains

Template slaves enable you to dynamically add slave domains without performing any configuration changes in PSAdmin .

When you create a template slave domain you import a domain configuration and save it as a template for the slave domain. This process creates a static slave domain that uses all of the pub/sub processes and queue lists configured for the domain that you import. If dedicated servers are configured for the domain that you import, they are imported and available on the slave domain. After you import a domain configuration and save it as a slave domain, you can add or remove dispatcher queues from the slave domain as needed.

All template slave domains must be based on the same master domain configuration.

Template Slave Domain Types

There are two options for importing a domain as a template:

Understanding Importing Domain Configurations

To import the domain configuration on which the template slave domain is based, you use the Import Domain Configuration command in PSAdmin . You can import a domain that is already configured in PSAdmin or you can import a domain configuration from a file.

To import a domain configuration from an application domain you specify the location of <PS_CFG_HOME> for the domain that you want to import. For example, the location might be c:\documents and settings\admin\psft\ps\<PS_CFG_HOME>.

To import a PeopleTools 8.49 or earlier application domain you must specify the <PS_HOME> location for <PS_CFG_HOME>. For example, the location might be c:\documents and settings\<PS_HOME>\<PS_CFG_HOME>.

Prerequisites for Importing Domain Configurations

If you are importing a domain that is already configured in PSAdmin, you must first set the PS_FILEDIR environment variable equal to the PS_HOME location of the domain you importing.

If importing a domain configuration from a file, you must first set the PS_FILEDIR environment variable to the location where you are importing the file.

Importing Domain Configurations from Files

To import a domain configuration from a file:

1. Open PSAdmin.

   The PeopleSoft Server Administration menu appears.

2. Enter 1 for Application Server and press the ENTER key.

   The PeopleSoft Application Server Administration menu appears.

3. Enter 4 for Import Domain Configuration and press the ENTER key.

   The PeopleSoft Import Application Server Configuration menu appears.

4. Enter 2 for Import IB Master Configuration and press the ENTER key.

   A Configuration Templates prompt appears.

5. Select one of the following options:

   • Enter 1 to import the domain as an IB Slave Basic template and press the ENTER key.

   • Enter 2 to import the domain as an IB Sync Slave template and press the ENTER key.

   The PeopleSoft Import Application Server Configuration menu appears.

6. Enter 1 for Import from file and press theENTER key.

   A prompt displays to enter the full path to the domain configuration file to import.

7. Enter the full path to the domain configuration file to import and press the ENTER key.

   A prompt displays to enter a name for the new domain.

8. Enter a name for the new domain and press the ENTER key.

The system merges the domain configuration with the new template slave domain and creates the new configuration and loads it on the application server. Upon completion, the PeopleSoft Domain Administration menu appears, where you may boot the template slave domain, configure the template slave domain or perform other administrative tasks.

Importing Domain Configurations from Application Domains

To import a domain configuration from an application domain:

1. Open PSAdmin.

   The PeopleSoft Server Administration menu appears.

2. Enter 1 for Application Server and press the ENTER key.

   The PeopleSoft Application Server Administration menu appears.

3. Enter 4 for Import Domain Configuration and press the ENTER key.

   The PeopleSoft Import Application Server Configuration menu appears.

4. Enter 2 for Import IB Master Configuration and press the ENTER key.

   A Configuration Templates prompt appears.

5. Select one of the following options:

   • Enter 1 to import the domain as an IB Slave Basic template and press the ENTER key.

   • Enter 2 to import the domain as an IB Sync Slave template and press the ENTER key.

   The PeopleSoft Import Application Server Configuration menu appears.

6. Enter 2 to for Import from application domain and press theENTER key.

   A prompt displays to enter the location of <PS_CFG_HOME>.

7. Enter the location of <PS_CFG_HOME> and press theENTER key.

   The Tuxedo Domain List appears that lists the application domains that you can import.

8. Enter the number that corresponds to the application domain to import.

   A prompt displays to enter a name for the new domain.

9. Enter a name for the new domain and press the ENTER key.

The system merges the domain configuration with the new template slave domain and creates the new configuration and loads it on the application server. Upon completion, the PeopleSoft Domain Administration menu appears, where you may boot the template slave domain, configure the template slave domain or perform other administrative tasks.

Adding and Removing Dispatcher Queues from Template Slave Domains

This section applies only to asynchronous slave templates.

Template slave domains contain all of the dispatcher queues that exist on the domain on which it is based. However, you can add and remove queues to configure the template slave domain to suit your requirements.

Note. Before you can add or remove queues from a template slave, you must inactivate all domains.

The Slave Templates page (IB_DOMAIN2_SEC) lists the dispatcher queues assigned to each dispatcher process of the template slave. The following example shows a partial view of the Slave Templates page:

From the Slave Templates page, you can use the Add/Remove Queues link located under each dispatcher process name to access the Add/Remove Queues page to add or remove queues assigned to the dispatcher. The following example shows the Add/Remove Queues page:

Note that the previous graphic shows a partial queue list for the domain.

On the Add/Remove Queues page you can use the plus (+) button to add a queue to the queue list. Use the minus (-) button to remove a queue from the list.

To add or remove dispatcher queues for template slaves:

1. Access the Domain Status page (PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status).

2. Check the All Domains Inactive box and click the Update button.

   The Force Reset button appears.

3. Click the Force Reset button to reset any contacts that are in a Started or Working state.

4. Click the Slave Templates link.

   The Slave Templates page appears.

5. Click the Add/Remove Queues link for a queue dispatcher.

   The Add/Remove Queues page appears and displays the queue list for the dispatcher.

6. To add a queue:

   1. Click the plus (+) button to insert a new row into the list.

   2. Click the Lookup button to search for a queue to add.

   3. Click the OK button at the bottom of the Add/Remove Queues page.

      The Slave Templates page appears.

   4. Click the Update button.

      The Domain Status page appears.

7. To delete a queue:

   1. Click the minus (-) button next to the queue to delete.

   2. Click the OK button in the dialog box to confirm the delete action.

   3. Click the OK button at the bottom of the Add/Remove Queues page.

      The Slave Templates page appears.

   4. Click the Update button.

      The Domain Status page appears.

8. Activate the domains in the messaging system.

   Check the All Domains Active box and click the Update button to activate the domains.

Restoring Template Slave Dispatcher Queue Lists

Restoring a queue list deletes any changes you have made to a template slave dispatcher queue list, and restores it to the queue list that you originally imported from the master domain.

To restore a template slave queue list, use the Slave Template Cleanup page (IB_DOMAIN3_SEC) shown in the following example:

In the previous example, PSBRKDSP_dflt appears in the Dispatcher Name field, meaning that additions or deletions have been made to the queue. In this example, you could use the page to restore the default template slave dispatcher list for PSBRKDSP_dflt.

To restore a template slave dispatcher queue list, you must first inactivate all domains on the system.

To restore a template slave dispatcher queue list:

1. Inactivate the domains on the messaging system:

   1. Access the Domain Status page (PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status).

   2. Check the All Domains Inactive box and click the Update button.

      The Force Reset button appears.

   3. Click the Force Reset button to reset any contacts that are in a Started or Working state.

2. Access the Slave Template Cleanup page:

   1. From the Domain Status page, click the Slave Templates link.

      The Slave Templates page appears.

   2. On the Slave Templates page, click the Slave Template Cleanup link.

      The Slave Template Cleanup page appears.

3. Check the box next to each dispatcher process name for which you want to restore the default queue list.

4. Click the Restore Default(s) button.

   The Domain Status page appears.

5. Activate the domains in the messaging system.

   Check the All Domains Active box and click the Update button to activate the domains.

Implementing Master-Slave Load Balancing

This section provides and overview of master-slave load balancing and discusses how to set up master-slave load balancing on the PeopleSoft system.

Understanding Master-Slave Load Balancing

You can implement master-slave load balancing on the integration system to compensate for processing capabilities of various machines on which master domains and slave domains run.

As an example, you might have a domain on machine that is also running the PeopleSoft Pure Internet Architecture. In this case, you could configure master-slave load balancing such that the machine that is running the PeopleSoft Pure Internet Architecture processes fewer requests than other machines on which domains reside.

Another example is a situation where the machines on which you are running domains have different processing capabilities due to the hardware installed in them. In this situation you can configure the machines with the most process power to process the greater number of requests.

To configure master-slave load balancing, you assign a weight between1 and 10 to each domain to distribute request processing. A domain assigned a weighted value of 1 processes the fewest requests; a domain assigned a weighted value of 10 processes the greatest number of requests.

Setting Up Master-Slave Load Balancing

You set up master-slave load balancing using the Master/Slave Load Balancing page (IB_DOMAIN_SEC).

To set up master/slave load balancing, you assign a processing weight value to each domain. The domain with the lowest number processes the fewest number of requests and is the master domain. The domains with the higher numbers are the slave domains and process the greatest number of requests.

The following example shows master/slave load balancing set up for the system:

The Domain section on the page lists information for the master domain, while the Static/Template Slave Domains section lists information about static slave domains.

The example shows two domains configured on one machine. The domain listed in the Domains section, QEDMO, is the master domain and has a load balance weight of 1 assigned to it. Given the load balance weight assigned to the domain, it processes the fewest number of requests.

The domain listed in the Static/Template Slave Domains section, DOMAIN002, has a load balance weight of 5 assigned to it. It processes a greater number of requests than the master domain.

To set up master-slave load balancing:

1. Access the Master/Slave Load Balance page (select PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status. Click the Master/Slave Load Balance link.)

2. For each domain select a value from the Weighted drop-down list box to assign a load balancing weight for the domain.

3. Click the OK button.

Setting Up Master-Slave Load Balancing for Long-Running Events

Typical master-slave load balancing usually focuses on normal events running at a high throughput. However, there are some instances where there are low volume service operation that contain long-running events. For better performance, you can assign these types of service operation to long-running event queues, where the processing is spread across all potential master and slave handlers.

You use the IB Long Running Event Queues page (IB_DOMAIN4_SEC) to assign service operations to long-running event queues. The following example shows the page:

To assign a service operation to a long-running event queue, you add the service operation queue that is currently defined on the service operation definition to one of the dispatcher queues on the page. When you click the Add/Remove Queues link for one of the dispatchers, the Add/Remove Queues page (PSIBQUEUE_SEC) appears. The Add/Remove Queues page is shown in the following example:

You use the Lookup button on the page to search for the service operation queue to which the service operation is assigned. When you click the OK button, the IB Long Running Event Queues page appears and the queue you specified appears in the dispatcher Queue field. The following example shows the IB Long Running Event Queues page when the FLIGHTQUEUE has been added to the Broker Dispatcher queue:

The following table describes the proper dispatchers to which to assign service operation queues based on the type of processing required:

Important! Do not assign service operations that contain long-running events to the same queues as those that do not contain long-running events. Processing performance for the normal high-volume service operations can be impacted.

To assign a service operation to a long-running event queue:

1. Access the Domain Status page (PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status).

   The Domain Status page appears.

2. Inactivate the domain.

   In the Domains grid, locate the Domain Status drop-down list box and select Inactive.

3. Click the Force Reset button.

4. Click the Master/Slave Load Balance link.

   The Master/Slave Load Balance page appears.

5. Click the Add Long Running Event Queues link.

   The IB Long Running Event Queues page appears.

6. Click the Add/Delete Queue link for the dispatcher to which to add the service operation queue.

   The Add/Remove Queues page appears.

7. Enter or use the Lookup button to search for the name of the queue to which the service operation is assigned.

8. Click the Update button.

   The Master/Slave Load Balance page appears.

9. Click the OK button.

   The Domain Status page appears.

10. Activate the domain by selecting Active from the Domain Status drop-down list in the Domains grid.

11. Click the Update button.

Implementing Deferred Master Domain Processing

This section provides an overview of deferred master domain processing and discusses how to set up deferred master domain processing.

Understanding Deferred Master Processing

PeopleSoft Integration Broker enables you to defer request processing on master domain to slave domains that are available for processing. Configuring deferred master processing enables you to free processing resources on the master domain machine due to hardware or processing power limitations, or so it can run other processes.

The Master/Slave Load Balance page features a Master Processing Status drop-down list box where you set the processing status for the master domain. The following table lists the master processing statuses and their descriptions.

If the system is set to any of the deferred modes the master will process requests if no slave dispatchers are available. In each of the deferred modes, the master assigns processing to slave dispatchers based on the load balancing weight value assigned to the slave dispatcher.

Setting Up Deferred Master Domain Processing

To set up deferred master domain processing:

1. Select PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status.

   The Domain Status page appears.

2. Click the Master/Slave Load Balance link.

   The Master/Slave Load Balance page appears.

3. From the Master Processing Status drop-down list box, select a master domain processing status.

   The valid values are:

   • Enabled

   • Deferred — All Queues

   • Deferred — Unordered Queues

4. Click the OK button.

Allowing Multiple Active Domains

By default, only one domain may be active in the Integration Broker system. However, PeopleSoft provides the option to enable the activation of multiple domains.

To allow multiple active domains, use the Monitor Setup Options page in the Service Operations Monitor.

To allow multiple active domains:

1. Access the Monitor Setup Options page (PeopleTools, Integration Broker, Service Operations Monitor, Administration, Monitor Setup Options).

2. Select the Allow Multiple Active Domains option.

3. Click the Save button.

Setting Up Domain Failover

This section discusses how to:

• Enable failover on domains.

• Set up dynamic master-slave dispatchers.

• Check the validity of queue sets.

• View queues assigned to failover groups.

• Schedule pause times for failover.

Understanding Domain Failover

This section discusses domain failover.

Domain Failover

Domain failover ensures that PeopleSoft Integration Broker continues processing message requests and responses, even if it incurs errors or other problems on the primary domain. When failover is activated, service operation processing will switch to back up domains should Integration Broker incur any errors or problems on the primary domain. In addition, should the domain fail, you can send a system-generated email notification to individuals.

If the connection with the database is lost and the handlers are processing service operations at that time, the handlers attempt to reboot. If initialization fails, the handlers are not rebooted. If you are using failover, the failover process takes over and failover of the domain occurs.

Domain Failover Groups

You can set up domain failover groups, so that all failover takes place on specific domains. To set up failover groups, you assign a domain a failover group number. After you assign domains to a group, you then assign the failover priority for all domains within the group.

Note. If you do not use dedicated messaging servers, you typically do not need to use failover groups.

Note. Queue sets within failover groups must be identical; queue sets between failover groups must be unique.

The example of the Failover Configuration page in the Enabling Failover on Domains section in this chapter shows five domains attached to the application server. The first three domains have been assigned to failover group one, as indicated by the value 1 in the Failover Group field for each domain. The last two domains have been assigned to failover group two, as indicated by the value 2 in the Failover Group field for each domain.

The failover priority within group one is as follows: the first domain in the list, QEDMO, is the main and primary back-up domain as indicated by the failover priority value 1; the second domain in the list,DOMAIN02, is the second back-up domain as indicated by the failover priority value 2; the third and final back-up domain for failover group one is indicated by the failover priority value 3 and is the domain DOMAIN03.

The failover priority within group two is as follows: the fourth domain in the list, DOMAIN04, is the first back-up domain for group two as indicated by the failover priority value 1; the last domain in the list, DOMAIN05, is the second back-up domain as indicated by the failover priority value 2.

Failover Groups — Priority Reset

PeopleSoft Integration Broker features a priority reset option that works in conjunction with failover groups.

When you set this option and failover occurs, the system attempts to use the domain defined as group priority value of 1 before failing over to the next sequential domain.

As an example, you could have a failover group defined as follows:

In our example, domain QEDMO has already failed over to domain DOMAIN02. If domain DOMAIN02 subsequently fails, the system attempts to failover back to the domain with the highest failover priority setting, domain QEDMO. If the system is unsuccessful in failing over to domainQEDMO, domain DOMAIN02 fails over to the next sequential domain in the failover group, domain DOMAIN03.

You set the Priority Reset option on the Failover Configuration page.

See Enabling Failover on Domains.

Dynamic and Static Master-Slave Dispatchers

You can implement master-slave dispatchers in conjunction with domain failover.

When dynamic slaves are implemented, the domain with the highest priority will become the active domain (master domain) in each group during failover. The next domain in priority is automatically programmatically configured as an active slave domain. You configure dynamic slaves in the Service Operations Monitor.

Static domain slaves are always slaves. You configure static slaves in PSAdmin.

Failover Priority — General Failover

In general domain failover, if a failover domain becomes inactive, the system attempts failover back to the highest priority domain. If it is unable to do so, the next domain prioritized becomes the active domain.

As an example, consider an integration system with the domains and failover priorities shown in the following table:

In this integration system if Domain A fails, the system will failover to Domain B. If Domain B later fails, the system attempts to failover back to Domain A. If it is unable to do so, the system will failover to Domain C.

Failover Priority — Dynamic Slave Failover

In dynamic slave failover, if the dynamic slave fails, the system generates and email notification and the dynamic slave becomes inactive. The system does not failover to find another dynamic slave.

Failover on the primary system has to occur for a dynamic slave to automatically go into effect.

Failover Priority Modification

If you modify failover priorities when failover is enabled and change the priorities of the current active domain, all domains are reset to inactive and the domain with the priority value of 1 is activated. However, if failover is not active and you change priorities, PeopleSoft Integration Broker saves the changes without any domain status reset.

Failover and Node Pause Times

Domain failover is disabled during node/system pause times. Additional information is provided elsewhere PeopleBooks.

See Understanding Pausing Nodes.

You can add scheduled pause times to nodes during which time failover does not occur. A typical case for scheduling system pause times is for scheduled or routine system maintenance. Scheduling pause times prevents failover from occurring during the defined time range and notifications from being sent when a domain is brought back up.

See Scheduling Pause Times for Failover.

Enabling Failover on Domains

Use the Failover Configuration page (IB_AMM_FAILOVER) to enable failover on domains. The following example shows the page:

To set up domain failover:

1. Access the Failover Configure page (PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status and click the Set Up Failover link).

2. Select the Enable Failover box.

3. In the IB Failover Time (minutes) field, specify the number of minutes that can pass without the domain registering itself before the failover should commence

4. (Optional.) To implement dynamic slaves, select the Dynamic Slave Option.

5. (Optional.) In the Failover Group field, enter a numeric value to specify a group to which a domain belongs.

   A value of 1 indicates that the domain is the first backup domain; a value of 2 indicates that the domain is the second back-up domain if the first backup domain fails; and so on.

6. In the Failover Priority field, enter a numeric value to specify the priority for a back up domain in the failover configuration.

   A value of 1 indicates that the domain is the first backup domain; a value of 2 indicates that the domain is the second back up domain; and so on.

7. (Optional.) In the Email_TO field, specify the email addresses of people to whom the system sends a notification about the domain failure if it occurs.

   Separate multiple email addresses with a semicolon.

8. (Optional.) In the Email_CC field, specify the email addresses of people who receive copies of the domain failure notification.

   Separate multiple email addresses with a semicolon.

9. Click the Save button.

Setting Up Dynamic Master-Slave Dispatchers

When dynamic slaves have been set the Slave Indicator column on the Failover Configuration page displays the status Dynamic to indicate the domains that are serving as dynamic slaves.

The following example shows the Failover Configuration page with two dynamic slaves in place.

As noted earlier, the domain in a failover group with the highest priority becomes the master and the domain with the second highest priority becomes the slave.

To set up master-slave dispatchers, follow the procedure for setting up failover and verify that you:

• Check the Enable Failover box.

• Check the Dynamic Slave Option box.

• Set up at least one failover group that contains at least two domains.

• Set a failover priority for each domain in the failover group.

• Save your settings.

Checking Queue Validity

Use the Check Group Validity link on the Failover Configuration page to verify that all queues assigned to the pub/sub processes in a failover group are the same.

When you click the link a message box appears that indicates if the group is valid.

Viewing Queues Assigned to Failover Groups

Use the View Group Queues link on the Failover Configuration page to view the queues assigned to each dispatcher in a failover group. Queues must be identical among all groups.

Scheduling Pause Times for Failover

Use the Node Status page (AMM_NODE_STATUS) in the Service Operations Monitor to schedule pause times for failover. To access the page select PeopleTools, Integration Broker, Service Operations Monitor, Administration, Node Status. The following example shows the page:

When you click the Add Pause button the Set Message Node Pause Interval page (AMM_ADD_SPTIMES) appears where you can set the system pause start and stop day and time. The following example shows the Set Message Pause Time Interval page:

To schedule a pause time for failover:

1. Access the Node Status page (PeopleTools, Integration Broker, Service Operations Monitor, Administration, Node Status).

2. Click the Add Pause button.

   The Set Message Node Pause Interval page appears.

3. Schedule the pause time to start:

   1. From the Start Day drop-down list, select the day of the week for the pause time to start.

   2. In the Start Time field, enter the time of day for the pause time to start.

4. Schedule the pause time to end:

   1. From the End Day drop-down list, select the day of the week for the pause time to end.

   2. In the End Time field, enter the time of day for the pause time to end.

5. Click the OK button.

   The Node Status page appears and the details of the scheduled pause time appear in the Asynchronous Pause Time grid.

See Also

Pausing, Testing, and Pinging Nodes

Configuring Integration Gateways for Load Balancing When Using Third-Party Software

This section discusses how to configure integration gateways in conjunction with using third-party load balancing software.

Understanding Configuring Integration Gateway for Load Balancing When Using Third-Party Software

To increase gateway performance you can use load balancing using third-party software. Load balancing involves the use of a third-party load balancing software product and the installation and configuration of multiple gateways. Then, when messages are sent or published to your messaging system, the load balancing software analyzes the load on installed gateways and determines to which gateway to send the messages to balance the load on all gateways.

For installation and configuration information about your load balancing software, please see the documentation that is included with the product.

Configuring Load Balancing on Integration Gateways When Using Third-Party Software

To configure gateways participating in load balancing, you must specify the URLs of the gateways in use for load balancing on the Gateways page, and then set integration gateway properties for each gateway you specify. Note that you can set different properties for each gateway.

To access the Gateways page, select PeopleTools, Integration Broker, Integration Setup, Gateways. Select the default local gateway.

To configure an integration gateway for load balancing:

1. Access the Gateways page (PeopleTools, Integration Broker, Integration Setup, Gateways.

2. Select the default local gateway.

3. Select the Load Balancer box.

4. In the Physical Gateway section, in the URL field, enter a gateway URL for a gateway that will be used for load balancing.

5. Click the plus (+) button and enter gateway URLs for each additional gateway to be used for load balancing.

6. Click the Save button.

7. For each gateway URL entered, click the Properties link to set integration gateway properties for that gateway.

See Also

Managing Integration Gateways

Implementing Load Balancing on Service Operation Queues

This section discusses implementing load balancing on service operation queues.

Understanding Implementing Load Balancing on Service Operation Queues

PeopleSoft provides the ability to load balance queue processing on active pub/sub systems using the Load Balance Interval parameter in PSAdmin.

Load Balancing on Pub/Sub Systems

PeopleSoft provides the ability to load balance queue processing on active pub/sub systems using the Load Balance Interval parameter in PSAdmin.

Note. The Load Balance Interval parameter is the same parameter used to resubmit failed transactions.

For example, without the Load Balance Interval parameter set, if there are three queues that have service operations to process, only one queue gets processed at a time. Moreover, as TPA calls continue to be generated, the dispatcher looks in the same queue to process service operations, resulting in that single queue performing most of the processing. This scenario happens most frequently when publishing in batch mode. As long as there are service operations in that one queue, the system does not process any service operations in any other queue.

However, when you set the Load Balance Interval parameter and the value you set is exceeded, the system dispatches all queues. This means that other queues that can be processed will be processed, at least partially, for the interval time designated.

Multi-Queue Processing

Multi-queue processing enables you to assign multiple queues for unordered service operation transaction processing.

When you configure multi-queue processing, a service operation transaction are processed one at a time on a rotating basis among all queues defined for multi-queue processing. You can also use this feature for

See Also

Specifying Dispatcher Parameters

Implementing Load Balancing on Pub/Sub Systems

This section discusses load balancing on pub/sub systems.

Understanding Load Balancing on Pub/Sub Systems

You can implement load balancing on pub/sub systems by setting a value, in minutes, that determines the time interval between dispatcher processing of requests.

When implementing, processing consists of the system attempting to perform the equivalent of an on idle ping on all down nodes (without the ping interval delay) for the default publication contract dispatcher (_dflt). Moreover, for all dispatchers not configured as slaves when this interval is reached, the equivalent of on idle processing will be performed. This means that if other queues can be processed they will be for the current dispatch cycle.

Setting the Load Balance Interval Parameter

The Load Balance Interval parameter is located in the Settings for Pub/Sub Servers section of PSAdmin. By default this feature is disabled and has a default setting of 0. The value you set is the number of minutes between load balance processing.

See Also

Using the PSADMIN Utility

Implementing Inbound Request Load Balancing Using Virtual Application Server Domains

This section discusses how to:

• Configure a synchronous slave template domain.

• Define application server URLs for load balancing.

• Define gateway URLs for inbound processing.

• Define virtual server nodes.

• Register and synchronize integration gateways and virtual application server domains.

• View virtual server domains registered to an integration gateway.

• Enforce secure inbound requests.

Understanding Implementing Load Balancing Using Virtual Application Server Domains

You can configure one or more integration gateways for load balancing using virtual application server domains. This section provides an overview of implementing this process.

Synchronous Slave Template Domains

To implement load balancing using virtual application server domains you must configure a synchronous slave template domain in PSAdmin. When the application server boots, the slave template registers application server information to all gateways defined for inbound processing. You can view the slave templates that are registered to a gateway using the Inbound Gateways page in the Gateway component.

Note. The terms slave template domain and slave template are used interchangeably in this section.

When the application server is booted, the slave template domain appears in the Domain Status component in the Service Operations Monitor, where you perform additional configuration as well as manage dispatcher queues.

Load Balancing Application Server URLs

When you boot the slave template domain, it appears in the Domain Status component in the Service Operations Monitor. Synchronous slave templates are indicated in the system as Sync-Template.

You then use the Slave Templates page to add the application server URL information (machine name: jolt port) in order for the gateway(s) to make a proper connection to that particular domain.

Gateway URLs and Inbound Gateway Processing

If you are using multiple gateways, you then use the Inbound Gateways page in the Gateways component to add gateway URLs for each physical gateway that you are using. The URL of the default local gateway is populated on the page by default.

You can also use the Inbound Gateways page to view current service URLs assigned to nodes.

Virtual Server Nodes

You can define a virtual server node so that in situations where an inbound request does not specify a “To” node, the system will send the request to a PeopleSoft node defined in the integration gateway properties file.

Secure Inbound Requests

The integration gateway properties file features a property, ig.SecureVirtualRequests, that enables you to require that all inbound requests be sent using SSL/TLS. When this property is set to True, the gateway accepts only those requests that are sent using SSL/TLS.

Configuring Synchronous Slave Template Domains

The first step to implementing load balancing using virtual applications server domains is to configure a synchronous slave template domain.

You use PSAdmin to create synchronous slave template domains, selecting the IB Sync Slave configuration template option. Creating slave templates is described elsewhere in this PeopleBook.

See Creating Template Slave Domains.

After you create a synchronous slave template, the domain and its dispatcher processes appear on the Domain Status page in the Service Operations Monitor. To access the page, select PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status:

The Domains section of the page shows the master domain as well as one synchronous slave template domain. Note that the Slave Indicator column for the synchronous slave template reads Sync Template to identify it as a synchronous slave template. The Dispatcher Status section displays the dispatcher processes for both the master domain and the synchronous slave template domain.

Define Application Server URLs for Load Balancing

After you create a synchronous slave template domain, the next step for implementing load balancing using virtual application server domains is to define the application server URL on the synchronous slave template domain. Doing so enables the integration gateway(s) to make a proper connection to that particular synchronous slave template domain.

Use the Synchronous section of the Slave Templates page to define application server URLs for synchronous slave templates. The following example shows the Synchronous section of the Slave Templates page. To access the page select PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status, and click the Slave Templates link.

To define application server URLs for load balancing:

1. Access the Slave Templates page (PeopleTools, Integration Broker, Service Operations Monitor, Administration, Domain Status, and click the Slave Templates link).

2. In the Synchronous section at the top of the page, enter an application server URL that the integration gateway is to use to connect to the domain. Enter the application server URL information in the following format:

   //<machine name>:<jolt port>

3. Click the Update button.

Defining Integration Gateways URLs for Inbound Processing

The system automatically uses the default local gateway for inbound request processing. You can add additional gateways to distribute processing tasks by using the Inbound Gateways page (IB_GATEWAY_SEC) in the Gateways component.

To access the Inbound Gateways page, select PeopleTools, Integration Broker, Configuration, Gateways and click the Inbound Gateways link. The following example shows the page:

To integration gateway URLs for inbound processing.

1. Access the Inbound Gateways page (PeopleTools, Integration Broker, Configuration, Gateways and click the Inbound Gateways link).

2. Add row to the Inbound Gateways grid by click the add a row icon (+).

3. Enter a gateway URL in the following format:

   http://machinename:port/PSIGW/PeopleSoftListeningConnector
   

   In this case, machinename:port is the machine name and port, host name, or IP address of the web server hosting the gateway.

4. Click the Update button.

See Also

Defining Virtual Server Nodes

Defining Virtual Server Nodes

When an inbound request is sent without a destination node indicated, you can specify that a PeopleSoft node (as defined in the integration gateway properties file) process the request.

Note. Defining a virtual server node is optional.

The PeopleSoft Node Configuration page features a Virtual Server Node field. When you want a PeopleSoft node to process an inbound request that was sent without a destination node, the integration system directs the request to the node specified in the field.

The following example shows the PeopleSoft Node Configuration page:

The example shows that the value PSFT_NODE_02 is entered in the Virtual Server Node field. As a result, inbound requests that do not specify a destination node, are sent to the PSFT_NODE__02 node.

You can also specify a virtual server node directly in the integrationGateway.properties file by setting the following property equal to the PeopleSoft node you want to handle the request:

ig.isc.virtualserverNode

If you specify this information directly in the integrationGateway.properties file, the JOLT connect information must adhere to the example provide in the example in the file. The order of properties must not deviate from the example provided in the properties file, shown here:

#ig.isc.virtualServerNode=VIRTUALSERVERNODE
#ig.isc.serverURL=//MYSERVER:9000
#ig.isc.userid=MYUSERID
#Use the supplied "Password Encryption Utility" to generate an encrypted password⇒
 for the next entry.
#ig.isc.password=ENCYRPTEDMYPASSWORD
#ig.isc.toolsRel=8.46
#Use the supplied "Password Encryption Utility" to generate an encrypted password⇒
 for the next entry.
#ig.isc.domainConnectionPwd=ENCRYPTEDDOMAINPASSWORD 

Registering and Synchronizing Integration Gateways and Virtual Application Server Domains

This section discusses registering and synchronizing integration gateways and virtual application server domains.

Registering and Synchronizing Virtual Application Server Domains with Gateways

When you boot a virtual server it automatically registers itself with the gateways defined on the Inbound Gateways (IB_GATEWAY_SEC) page. Subsequently, when you shut down a virtual server it automatically de-register itself.

However, you may find a need for manual registration in situations where automatic registration process fails, a gateway is down, and so on. You can manually register a virtual server domain by using the Sync button on the Inbound Gateways page. To access the Inbound Gateways page, select PeopleTools, Integration Broker, Configuration, Gateways, and click the Inbound Gateways link.

Registering and Synchronizing Virtual Application Server Domains with Nodes

When the gateway is booted, upon initialization the system checks the parameter ig.isc.VirtualSynchronization in the integration gateway properties file. If set to True, the system looks at all known nodes that are set to the Tools release 8.51 and makes a call to those endpoints to get the virtual server information.

The ig.isc.VirtualSynchronization property appears in the Virtual Server section of the integration gateway properties file.

See Using the integrationGateway.properties File.

Viewing Virtual Application Server Domains Registered to Integration Gateways

The Gateway Server URLs page (IB_GWSERVER_SEC) lists the server URLs assigned to each node for a particular integration gateway. To access the Gateway Server URLs page, select PeopleTools, Integration Broker, Configuration, Inbound Gateways, and click the View Details link for a gateway. The following example shows the page:

Enforcing Secure Inbound Requests

You can require that all inbound requests be sent using SSL/TLS.

To do set, set the following property in the integrationGateway.properties file to True.

ig.SecureVirtualRequests=True

This property is located in the Virtual Server Section of the properties file.

When this property is set to True, the gateway accepts only those requests that are sent using SSL/TLS.

Resubmitting Failed Transactions

The PSADMIN parameter Load Balance Interval enables you to resubmit failed transactions for processing.

This functionality allow transactions that failed due to a connection problem to be retried periodically. The benefit of this is to unblock a queue and have it be able to process in a more load balancing way.

Note. The Load Balance Interval parameter is the same parameter used to implement load balancing on service operation queues.

The Load Balance Interval parameter is located in the Settings for Pub/Sub Servers section of PSAdmin. The value you set for the Load Balance Interval parameter determines the time interval (in minutes) between load balance processing when the dispatcher is processing requests.

When this parameter is enabled, processing consists of attempting to perform the equivalent using the Scan Interval parameter, without the delay. Moreover, when this load balance interval is reached the equivalent of the scan interval processing is performed on all default dispatchers, allowing other queues to process transactions.

When true scan interval processing is performed the load balance interval time is reset.

Note. Only the default publication contract dispatcher (_dflt) is used to ping these nodes. When the load balance interval is exceeded the default publication contract dispatcher performs the scan interval processing of pinging the nodes. If the actual scan interval processing is run before the load balancing interval is exceeded, then the system resets the load balance time value.

See Also

Specifying Dispatcher Parameters

Setting the Load Balance Interval Parameter

Using WS-Reliable Messaging

This section discusses how to:

• Use WS-Reliable Messaging on outbound service operations.

• Use WS-Reliable Messaging on inbound service operations.

Understanding WS-Reliable Messaging

Web Service (WS) Reliable Messaging is a protocol that allows SOAP messages to be delivered reliably between distributed applications in the presence of failures at the software component, system, or network level.

PeopleSoft supports a limited implementation of the WS-Reliable Messaging specification, intended for use in interoperating with Oracle BPEL Process Manager.

Using WS-Reliable Messaging on Outbound Service Operations

This section discusses using WS-Reliable Messaging on outbound service operations.

Understanding Using WS-Reliable Messaging on Outbound Service Operations

For outbound service operations, PeopleSoft supports WS-Reliable Messaging for asynchronous transactions.

Outbound service operations only support a single content section, which will correspond to a single message with a WS-Reliable Messaging sequence header block on the wire. Multiple contents sections, and therefore multiple runtime sequence messages, are not supported.

When using reliable messaging, message bodies should not be SOAP wrapped in the application server. The gateway builds a SOAP envelope as a by-product of the WS-Reliable Messaging processing.

During a successful invocation, three WS-Reliable Messaging messages are sent out on the wire: a CreateSequence, a message containing the message data as well as a Sequence header block, and a TerminateSequence message. If errors are seen during the transmission of a WS-Reliable Messaging message sequence, the gateway does not auto-recover. Errors are propagated back to the application server and it is the responsibility of the developer to handle further processing.

Enabling WS-Reliable Messaging on Outbound Service Operations

To use WS-Reliable Messaging on outbound transactions, use the HTTP target connector. The HTTP target connector features a gateway–level property called WS-RM. When you set the value of the property to Y, the transaction uses the WS-Reliable Messaging protocol for service operation delivery. Like any other HTTP target connector property, you can override the setting on the service operation routing or by using PeopleCode.

Setting the Value of AcksTo Endpoints in CreateSequence Messages

The integrationGateway.properties file features the following property that enables you to set the value of the AcksTo endpoint in CreateSequence messages:

ig.WSRM.CreateSequenceAcksTo=

The property is located in the WS Reliable Messaging section of the gateway properties file.

Note that the system expects to receive responses on the back channel, so the value you set for this property has no bearing on how the Integration Broker processes WS-Reliable Messaging response messages.

See Also

Editing Connector Properties

Using the integrationGateway.properties File

Using WS-Reliable Messaging on Inbound Service Operations

For inbound transactions, Integration Broker accepts the WS-Reliable Messaging protocol when posted into the PeopleSoft Service or HTTP listening connectors. The feature is triggered by the presence of the WS-Reliable Messaging namespace and headers in received SOAP messages.

Note that the WSDL does not reflect the use of WS-Reliable messaging.

For inbound service operations, PeopleSoft supports WS-Reliable Messaging for asynchronous transactions only. If an integration partner sends a synchronous transaction to Integration Broker using WS-Reliable messaging, an error message is returned to the sending system.

All inbound WS-Reliable Messaging communication between the sender and Integration Broker occurs in a single HTTP request-response transaction. The sender transmits a WS-Reliable Messaging message, Integration Broker receives and processes it, and then returns a WS-Reliable Messaging message in the HTTP response. Integration Broker ignores the value of AcksTo in CreateSequence messages.

Unlike outbound transactions using WS-Reliable Messaging, multiple Sequence messages are supported for inbound transactions.

Using the Bulk Load Handler for Large Message Subscriptions

PeopleSoft Integration Broker provides a bulk load handler type that serves as a bulk loader to insert data. This handler is available when working with asynchronous one-way service operation types.

See Implementing Handlers Using Bulk Load Processing.

Managing Pub/Sub Process Handler Performance

This section discusses how to:

• Enable the serial recycling of pub/sub process handlers.

• Recycle pub/sub process handlers based on process memory growth.

Enabling Serial Recycling of Pub/Sub Process Handlers

When serial recycle for pub/sub process handlers is enabled, the system recycles process handlers (within a group) on a serial basis–one after another–to allow processing to continue uninterrupted.

If serial recycling is disabled, all pub/sub process handlers recycle at once, which can cause throughput to come to a standstill.

By default the serial recycling of pub/sub process handlers is enabled.

Serial recycling uses the following parameters that you set in the psappsrv.cfg file in the Settings for PUB/SUB Servers section:

To enable serial recycling, uncomment the parameters in the psappsrv.cfg file and set the appropriate values. After you have made your changes, save the file and reboot the application server.

To disable serial recycling, comment out the parameters, save the file and reboot the application server.

Recycling Pub/Sub Process Handlers Based on Process Memory Growth

PeopleSoft Integration Broker enables you to recycle pub/sub process handlers based on memory growth in cache.

You use the Percentage of Memory Growth parameter in the psappsrv.cfg file to specify that the system recycle pub/sub process handlers when memory has grown by a value you specify. The system checks to see if the percentage criterion is met after processing a specified number of requests.

By default the Percentage of Memory Growth parameter is disabled.

This feature uses the following parameters that you set in the psappsrv.cfg file in the Settings for PUB/SUB Servers section:

To enable process handler recycling based on memory growth, uncomment the parameters in the psappsrv.cfg file and set the appropriate values. After you have made your changes, save the file and reboot the application server.

To disable process handler recycling based on memory growth, comment out the parameters, save the file and reboot the application server.