Using Integration Broker Monitor

This chapter discusses how to:

• Monitor message system information.

• Monitor asynchronous message details.

• View synchronous message details.

• View messaging system performance statistics.

• Run batch error notification processes.

• Run batch message archiving processes.

• Purge messaging tables.

• Use the Message Monitor component interface.

Understanding Integration Broker Monitor

This section lists prerequisites and common elements and discusses:

• Integration Broker Monitor features and components.

• Brokers, contractors, and queues.

• Message server processes.

• Dispatchers and handlers.

• Asynchronous message publication.

• Asynchronous message subscription.

• Synchronous message publication.

• Synchronous message subscription.

• Message status.

• Blocked and stalled channels

Prerequisites

Before using Integration Broker Monitor, set up security for it using permission lists. To set up permission lists, select PeopleTools, Security, Permissions & Roles, Permission Lists.

You use permission lists to grant access to the Integration Broker Monitor pages and to grant read and write access to message channels. Users can view messages only in channels to which they have read access. All edit actions require write access.

Common Elements Used in This Chapter

Integration Broker Monitor Features and Components

System administrators use Integration Broker Monitor to monitor asynchronous and synchronous message transaction information, status information, and other integration engine data.

Features

Integration Broker Monitor provides:

• Status on channels, nodes, and individual messages.

  You can also view and edit message XML.

• Control and administration of domains that have publication and subscribe (pub/sub) servers running against the current database.

  You can activate or deactivate domains, recover from stalls, and so forth.

• Workflow notification of error messages and archival of messages.

• Batch processes for error notification and message archival.

• Queries to gather information about messaging system metadata without your having to access PeopleSoft Application Designer.

  For example, you can perform queries to retrieve information about:

  • Transactions for a request or response message.

  • Messages that belong to each channel.

  • Channels and messages in the local node.

Components

There are five components associated with Integration Broker Monitor.

Brokers, Contractors and Queues

The Publication Broker, Publication Contractor, and Subscription Contractor services are the primary application server elements required for asynchronous messaging. The Publication Broker service routes the workload to both contractor server processes, as illustrated in the following diagram:

Brokers and contractors

Each broker or contractor has a queue to hold messages to process. The services perform the following functions:

Message Server Processes

The application server offers six server processes to handle asynchronous messages. They work in pairs to provide three primary services:

Dispatchers and Handlers

Each of the Publication Broker, Publication Contractor, and Subscription Contractor is comprised of two individual server processes that work together to handle incoming requests. One server process functions as a dispatcher, while the other functions as a handler.

This relationship is analogous to the way that the application server handles workstation connections and requests. To handle the incoming client requests, the application server has a listener and a handler (or a pool of handlers). The listener receives the incoming requests and then routes them to an available handler.

Typically, one listener serves many handlers. The relationship between the dispatcher and the handlers is analogous to the relationship between the Jolt Server Listener (JSL) and the Jolt Server Handler (JSH). In the case of the application messaging server processes, the dispatcher functions as the listener, and the handler as similar to the JSH.

For the services discussed in this section (Publication Contractor, Subscription Contractor, and Publication Broker) there are at least two server processes: a single dispatcher and one or more handlers. The PSxxxDSP server process is the dispatcher, and the PSxxxHND server process is the handler.

Note. The xxx represents BRK, PUB, or SUB. For example, in the case of the Publication Broker, PSBRKDSP is the dispatcher and PSBRKHND is the handler.

This diagram shows the messaging server processes grouped by their functions in the messaging architecture:

Dispatchers and handlers

Asynchronous Message Publication

This section describes the flow of an asynchronous message publication through PeopleSoft Integration Broker, as well as the status of the messages as they appear in Integration Broker Monitor.

Asynchronous Publish of a Message Instance

This diagram shows an asynchronous publish of a message instance:

Asynchronous publication of a message instance

The processing steps of an asynchronous publication of a message instance are:

1. The message is published and enters the message queue.

   The Broker Dispatcher process picks up the message instance from its queue. During this stage, the status of the message instance is New.

2. The Broker Dispatcher process passes the message instance to the Broker Handler process.

   During this stage, the status of the message instance is Started.

3. The Broker Handler process accepts the message instance, reads the data, and runs the routing rules to determine where the publication needs to be delivered.

   The Broker Handler process then writes a publication contract in the PSAPMSGPUBCON table and notifies the Publication Contractor service that it has an item to process. During this stage, the status of the message instance is Working.

4. After the message is stored in the publication contact queue, the status of the publication contract is New, the message instance status is Done, and the Publication Dispatcher process picks up the publication contract from its queue.

You view message instance status on the Message Instance page of Integration Broker Monitor. To access this page, select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message and select the Message Instance page.

Asynchronous Publish of a Publication Contract

This diagram shows the flow of an asynchronous publication contract:

Asynchronous publish of a publication contract

The processing steps of an asynchronous publish of a publication contract are:

1. The Publication Dispatcher process passes the publication contract to the Publication Handler process.

   At this stage the status of the publication contract is Started.

2. The Publication Handler process accepts the publication contract and attempts to deliver the message to the integration gateway.

   At this stage, the status of the publication contract is Working.

If the publication contract is successfully delivered to the destination node, the status is Done (refer to step 6c in the diagram).

If an error occurs during this stage, the status is Error.

If the system times out before the transaction is completed, the status is Timeout (6a in the diagram).

If the delivery fails, the Publication Handler process retries the delivery, and the status is Retry (refer to step 6b in the diagram). When messages have Retry status, the messages are not resent until an internal ping is successful. This ping is similar to a node ping. The Publication Contract Dispatcher, as part of its on idle processing, pings a node that is in Retry status and verifies if the connection is reestablished. When the ping is successful the Publication Contract Dispatcher resends the message. The message goes back to the Publication Handler process and returns to Working status.

You can view the status information for the publication contract in Integration Broker Monitor by selecting PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Pub Contracts.

See Also

Message Statuses

Asynchronous Message Subscription

This section describes the flow of an asynchronous message subscription through PeopleSoft Integration Broker, as well as the message status at each stage of the process.

Asynchronous Subscription of a Message Instance

This diagram illustrates the flow of an asynchronous message subscription through PeopleSoft Integration Broker:

Asynchronous subscription of a message instance

The processing steps are:

1. The message enters the message queue.

   The Broker Dispatcher process picks up the message instance from its queue. During this stage, the status of the message instance is New.

2. The Broker Dispatcher process passes the message instance to the Broker Handler process.

   During this stage, the status of the message instance is Started.

3. The Broker Handler process accepts the message instance, reads the data, and runs the subscription routing rules to determine if the message needs to be processed locally.

   The Broker Handler process then writes a subscription contract in the PSAPMSGPUBCON table (the subscription contract queue) and notifies the Subscription Contractor service that it has an item to process. During this stage, the status of the message instance is Working.

Once the message is stored in the subscription contact queue, the status of the subscription contract is New, the message instance status is Done, and the Subscription Dispatcher process picks up the subscription contract from its queue. In this example, at the point when the status of the asynchronous message instance is Done, the subscription contract status is New.

You view message instance status on the Message Instance page of Integration Broker Monitor. To access this page, select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message and select the Message Instance page.

Asynchronous Subscription Contract

This diagram shows the flow of an asynchronous subscription contract:

Asynchronous subscription contract

The processing steps are:

1. The Subscription Dispatcher process passes the subscription contract to the Subscription Handler process.

   At this stage the status of the subscription contract is Started.

2. The Subscription Handler process accepts the subscription contract and runs the subscription PeopleCode.

   In the example shown in the diagram, the subscription PeopleCode then uses the message data to update application data tables. However, the subscription PeopleCode can use the message data as input to look up information, create and publish another message, and so forth. At this stage, the status of the publication contract is Working.

   If the subscription PeopleCode runs successfully, the status is Done (refer to step 6a in the diagram). If an error occurs during this stage, the status is Error (refer to step 6b in the diagram).

To view status information for subscription contracts, use the Sub Contracts page in Integration Broker Monitor. To access this page, select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Sub Contracts.

See Also

Message Statuses

Synchronous Message Publication

This diagram illustrates synchronous message publishing through PeopleSoft Integration Broker:

Synchronous publication of a message instance

The processing steps are:

1. The system makes a SyncRequest ( ) call to PeopleSoft Integration Broker.

2. PeopleSoft Integration Broker sends the message to the integration gateway.

3. If the integration gateway can deliver the message to the destination node, the process is successful and the status is Done.

   If the process in unsuccessful, the status is Error.

You can view the status information for the publication in Integration Broker Monitor using the Synchronous Messages page. Access this page by selecting PeopleTools, Integration Broker, Monitor Integrations, Monitor Message and selecting the Synchronous Messages page.

See Also

Message Statuses

Synchronous Message Subscription

This diagram illustrates synchronous message subscription through PeopleSoft Integration Broker:

Synchronous subscription of a message instance

The processing steps are:

1. The integration gateway passes an inbound synchronous message to the integration engine.

2. The integration engine runs a subscription PeopleCode program.

3. The subscription PeopleCode program attempts to update the application data tables.

   If the program runs successfully, the status is Done. If the subscription PeopleCode program fails, the status is Error.

You can view the status information for the publication in Integration Broker Monitor by using the Synchronous Messages page. Access this page by selecting PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, and selecting the Synchronous Messages page.

See Also

Message Statuses

Message Statuses

This section discusses message status information that Integration Broker Monitor displays for synchronous and asynchronous messages.

Synchronous Message Statuses

For synchronous messages, Integration Broker Monitor displays one of two statuses.

Asynchronous Message Statuses

For asynchronous messages, Integration Broker Monitor displays different statuses as messages progress through the system.

The typical message status progression for asynchronous messages is:

1. New.

2. Started.

3. Working.

4. Contracts created.

However, Integration Broker Monitor can display any of the statuses listed in the following table.

Blocked and Stalled Channels

This section discusses:

• Blocked channels.

• Stalled channels.

Blocked Channels

Blocked channels preserve the order in which messages are processed.

The pub/sub system guarantees that items are processed in the order they are sent. If a message has a status of Error, Timeout, or Edited, the message queue becomes blocked and no processing occurs until you resolve the problem with the message.

For publications, channels are partitioned in queues by subchannels.

For publication contracts, the channel is further partitioned into queues by subchannel and target node. If a channel is ordered, items in that channel and in the same queue are processed in the order sent. The dispatcher does not begin processing an item until all items ahead of it in the queue have the status Done or Cancelled. An item with a status of Error, Timeout, or Edited blocks all items behind it in the same queue. If the remote node is unavailable, the dispatcher does not attempt to process the contract and the queue is blocked until the remote node becomes available. That is why publication contracts are partitioned by target node.

If a channel is unordered, an item (such as the publication, publication contract, or subscription contract) never blocks another item. All items are processed in parallel.

Stalled Channels

Stalls do not occur by design. They are caused by gaps in functionality, user errors, defects, and so forth.

For example, a channel can become stalled when:

• Multiple domains access the same database and one of the domains is shut down abnormally.

  Items may be stalled in the Started or Working status.

  Note. You can use the Domain Status page to correct the problem.

• A change occurs to the pub/sub runtime tables through direct SQL.

  The copies of the database tables that dispatchers have in memory are not updated. In this situation, you must reboot the dispatchers.

Monitoring Messaging System Information

You can monitor message system queue information by using the Monitor Message component (APPMSGMONITOR). The Monitor Message component enables you to view information about message instances, publication contracts, subscription contracts, synchronous messages, channel status, node status, and domain status. You can also use this component to generate related predefined queries.

This section discusses how to:

• Work with the Monitor Message component.

• Filter messaging information.

• View outputs.

• Monitor system queue information.

• Monitor asynchronous message instances.

• Monitor publication contracts.

• Monitor subscription contracts.

• Monitor synchronous message instances.

• Resubmit and cancel messages.

• View undelivered node transactions.

• Pause, test, and ping nodes.

• Monitor channel status.

• View channel partition information.

• Work with pub/sub server domains.

• Set up domain failover.

• View messaging system performance statistics.

• Run message queries.

• Archive message instances.

Working with the Monitor Message Component

This section discusses how to:

• Access the Monitor Message component.

• Use the Monitor Message component pages.

Accessing the Monitor Message Component

To access the Monitor Message component, select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message. By default the Overview page is active.

Using the Monitor Message Component Pages

The Monitor Message component consists of the following pages:

Filtering Messaging Information

Before you begin monitoring the messaging system, there are a few general guidelines that enable you to quickly drill down to the information you need.

Because the Integration Broker Monitor provides information about the entire messaging system, you need to understand how to filter the information to reduce the number of items. For instance, rather than sifting through every message in the entire system, the Integration Broker Monitor enables you to sort by publish node, publish date and time, live and archived messages, and so on.

You can filter the result set on the following pages of the Monitor Message component:

• Overview page

• Message Instances page

• Pub Contracts page

• Sub Contracts page

• Synchronous Messages page

You can use the following filter criteria on each page where filtering applies:

On the pages where filtering applies, you enter your filtering criteria in the Message Criteria group box. The result set appears in the status grid directly below the filtering options.

Saving Filtering Selections

You can save your filtering options so that the next time you use it, your previous filtering choices are set automatically.

To save filtering selections:

1. Select the filtering options that you want on the pages where filtering applies (namely, the Overview, Message Instances, Pub Contracts, and Sub Contracts pages).

2. Click Refresh on each page.

   Clicking Refresh not only refreshes the page according to the most recent filtering selections, it also saves the most recent filtering selections to the database. The system then associates a given set of filtering selections with your user ID. The next time that you sign in and launch Integration Broker Monitor, the system displays the message data according to your most recent filtering selections.

Viewing Output

The output in the results grids of the Monitor Message component enables you to view information by channel, date, status, and so on.

To sort the information that appears in the results grids, click a column heading.

After you locate a particular message status, publication contract, subscription contract or other item, click the Details link to view detailed data associated with the item. The system launches the Message Details component (AMM_DETAILS), the Synchronous Details component (AMM_SYNCDETAIL), or an application-specific page where you can view additional data and correct errors.

Whether you use the Message Details component, Synchronous Details component, or an application-specific page to view and edit a message depends on the properties of the message definition in PeopleSoft Application Designer. The Details link invokes a transfer page to the component that you can specify in Application Designer by selecting Message Definition, Message Properties, Error Viewing/Correction.

Monitoring System Queue Information

To monitor system queue information, select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message.

The Overview page is the first page that appears. Use this page for a high-level overview of the status of asynchronous message instances, publication contracts, and subscription contracts.

Depending on the information that you want, you then drill down further into the Message Instances page, the Pub Contracts page, and the Sub Contracts page.

Most of the time, the status for a message or channel that appears in the Queues scroll area is Done. This means that the message instance arrived in the publication queue (creating the message headers only). However, other statuses for a message or channel can appear. For instance, if the pub/sub system is down, the status is New. If there are transformation or OnRoute PeopleCode errors, the message status is Error. In addition, if you access Integration Broker Monitor at certain times, you might see a message status of Started or Working. Use the other pages in this component to view more comprehensive message status information.

In addition to using the filtering options discussed earlier in this chapter, you can filter the information on this page by using the following criteria:

After you select your filtering options, click Refresh.

See Also

Working with the Monitor Message Component

Monitoring Asynchronous Message Instances

Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Message Instances to access the Message Instances page.

The Message Instances page enables you to monitor the status and details related to individual asynchronous message instances. Every publication and subscription contract is associated with a message instance.

After you select your filtering options, click Refresh.

Note. All asynchronous transactions are sent to the publication queue regardless of whether the transactions are active or inactive. As a result inactive transactions that appear on the Message Instances page do not contain any publication contracts.

See Also

Working with the Monitor Message Component

Monitoring Publication Contracts

Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Pub Contracts to access the Pub Contracts page.

This page shows outbound publication work orders to send to remote nodes. The system does not create publication contracts for routing to the local node.

After you select the filtering options, click Refresh to update the message criteria.

See Also

Working with the Monitor Message Component

Monitoring Subscription Contracts

Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Sub Contracts to access the Sub Contracts page.

The Sub Contracts page enables you to view work orders and run the PeopleCode programs to which the local node subscribes. Subscription contracts for remote nodes do not appear.

Note. When viewing the status of bulk subscription contracts (such as 100,000 or more) using a Solaris operating system and an Oracle database, your browser session may close unexpectedly. As a result, you should filter the number of subscription contracts for which to view status information. To do so, use the Last drop-down list box to select whether to filter information by the day, hour, or minute. In the box to the left of the drop-down list box, enter the number of days, hours, or minutes. The volume of messages in the system determines the best values to enter.

See Also

Working with the Monitor Message Component

Monitoring Synchronous Message Instances

Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Synchronous Messages to access the Synchronous Messages page.

The Synchronous Messages page displays inbound synchronous messages from remote nodes or applications that publish information.

See Also

Working with the Monitor Message Component

Resubmitting and Canceling Messages for Processing

The Message Instances page, Pub Contracts page, Sub Contracts page, and Synchronous Messages page of the Monitor Message component enable you to resubmit and cancel individual and bulk messages for processing.

Working with Individual Messages

To resubmit or cancel individual messages, select the check box next to the appropriate messages and click the Resubmit Message or Cancel Message button.

To deselect a message, clear the check box next to the message.

Working with Bulk Messages

In addition to the Clear All, Resubmit Message, and Cancel Message buttons, you also use the following link when working with bulk message.

To deselect messages, click the Clear All button.

Viewing Undelivered Node Transactions

Integration Broker Monitor provides a Transaction Retry Queue link for read-only access to information about undelivered node transactions, such as the node name, transaction type, request message, and request message version.

You can access this information from the following pages in the Message Monitor component:

• Pub Contracts page.

• Node Status page.

Undelivered node transaction information is stored in the Nodes Down table. The Force Retry All button on the Undelivered Node Transaction page enables you to clear the table so that the system can attempt to restart any nodes that are down.

For example, if a node is in the Nodes Down table and you change the URL of the node, the node becomes free because it is still treated as inoperative (or down) based on the old URL. When you click the Force Retry All button, the system retries starting the node.

The Transaction Retry Queue link appears on the Pub Contracts page and provides access to the Undelivered Node Transaction page. Use the Undelivered Node Transaction page for read-only access to information about undelivered node transactions.

Click the Force Retry All button on the Undelivered Node Transaction page to clear the Nodes Down table so that the system can restart any nodes that are down.

See Also

Working with the Monitor Message Component

Pausing, Testing, and Pinging Nodes

Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Node Status to access the Node Status page.

This section discusses how to:

• Add a pause time to a local node.

• Test local nodes.

• Ping remote nodes.

Adding Pause Times to Local Nodes

A pause time is an interval of time during which the message node becomes inactive. When the pause time begins, the message node is shut down until the pause time is scheduled to end.

You might schedule a pause time to perform maintenance tasks or devote server resources to an important batch run. For example, say that you have a complex batch program that runs on the same server as a particular message node every Monday morning from 12:05 a.m. to 3:30 a.m. To make sure that the batch program has enough memory devoted to it, you can set a pause time for the message node that runs from 12 a.m. to 4 a.m.

During a pause time, messages are not published or received by the local system. When the system is paused, the node cannot accept messages sent to it. Consequently, the publishing node must attempt to send messages again later. The publishing node continues to send messages until it exceeds the local timeout period. When this happens, the message assumes a Timeout status in the publisher’s message queue. The timeout period is an attribute of the publication channel, not the subscription channel.

If the system attempts to send a message while the node is paused, the system writes the message to the publication and subscription queues, but it cannot publish the message until the system is no longer in the paused state.

Note. Pause times do not appear in PeopleSoft Application Designer upgrade projects; you cannot upgrade them.

To add a node pause time:

1. Click Add Pause.

2. Select a day of the week in the Start Day drop-down list box.

3. Enter a value in the Start Time edit box.

4. Select a day of the week in the End Day drop-down list box.

5. Enter a value in the End Time edit box.

6. After you have entered the appropriate start and end values to define your pause interval, click OK.

Deleting Pause Times

To delete an existing pause time:

1. In the pause time list, locate the pause time (interval) to delete.

2. Click the Delete button to the right of the entry in the pause time list.

Testing Local Nodes

To test the local node:

1. Make sure you are logged on to the node that you want to test.

2. Click the Test Node button.

Pinging Remote Nodes

A successful ping indicates that the remote node is available to receive messages. An unsuccessful ping could indicate that the node, gateway, or both are not running.

To ping a remote node:

1. In the Ping a Node to Determine Availability section, select the node in the Message Node Name drop-down list box to display a list of active nodes.

   The Location column in the grid below reveals the locations defined for the node.

2. Click the Ping Node button.

   The Node Information Section displays connector information defined for the node.

You can also ping remote nodes from the Send Master utility as well as the Simple Post utility.

See Using the Send Master Utility, Using the Simple Post Utility.

Monitoring Channel Status

Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Channel Status to access the Channel Status page.

The Channel Status page displays the status of the channels defined in the local node. A channel has two states: Running and Paused. If you notice a backup within a particular channel, check this page to make sure that the channel is running.

Occasionally, you might need to shut down a particular node to perform a specific maintenance task. Typically, a node contains numerous channels. If you shut down one channel, channels on the node continue processing messages undisturbed.

To determine the status of a channel, locate it within the Channel Name list, and then check the corresponding value in the Status column.

Viewing Channel Partitioning Information

If channel partitioning exists for a channel, a Sub Channel column appears in the results grid on the Message Instances page, the Pub Contracts page, and the Sub Contracts page of the Monitor Message component.

If you click the subchannel name link, the Sub Channel Message Queue page displays and you can view all messages in the sub channel in the order in which they will be processed. You can also resubmit messages or cancel the submission of messages on this page.

Working with Pub/Sub Server Domains

Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Domain Status to access the Domain Status page.

PeopleSoft Integration Broker includes a set of BEA Tuxedo servers that monitor database tables and process items in the tables. The processing can include running PeopleCode programs, creating publication and subscription contracts, and so forth.

The Domain Status page enables you to view the domains that have pub/sub servers on them that are running against the application database. You can also use this page to manually set domain grace periods to allow processing in a domain to finish before you pause the processing or take the domain offline.

In addition, if a machine with a domain on it crashes, the messaging system may still operate as if the processes in the domain are still working on items in the runtime tables. The Domain Status page enables you to set the domains to inactive so that other pub/sub servers can complete the processing of these items. This enables you to recover from domain and machine crashes.

This section discusses how to work with the Domain Status page and how to:

• View dispatcher status.

• Activating pub/sub server domains.

• Inactivate pub/sub server domains.

• Change dispatcher status for processes.

• Set domain grace periods.

Working with the Domain Status Page

The Domain Status page features three sections, the Domain Criteria section, the Domain Status section, and the Dispatcher Status section.

The Domain Criteria section enables you to perform actions on all domains in the messaging system, such as apply a grace period to all domains, activate or inactivate all domains, and purge the current information in the Dispatcher Status section.

The Domain Status section provides application server name and path information for all machines that have domains on the messaging system. For any machine, you can use the drop-down list to activate or inactivate the machine and all domains on it. You can also set grace periods for domains on specific machines.

The Domain Status page also features the following controls:

Viewing Dispatcher Status

The Dispatcher Status section displays information about machines in the messaging system that have dispatcher processes associated with them. This area displays the machine name, the dispatcher process name, the application server path, the dispatcher status, and any grace periods set for a process running on the domain.

There are three valid dispatcher status values:

Activating Pub/Sub Server Domains

Before you can use the pub/sub system, you must activate the domain on which a pub/sub server resides.

To activate a domain:

1. Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message.

2. Select the Domain Status tab.

   The Domain Status page appears.

3. In the Domains section:

   1. Locate the row that lists the machine where the domain resides that you want to activate.

   2. In the Domain Status drop-down list box, select Active.

4. Click the Update button.

Inactivating Pub/Sub Server Domains

To inactivate pub/sub servers on domains:

1. Inactivate pub/sub server domains:

   1. To inactivate domains on all machines in the messaging system, select the All Domains Inactive check box. To activate the servers at a later time, select the All Domains Active box.

   2. To inactivate domains on individual machines, locate the domains to inactivate. In the drop-down list box, select Inactivate. To activate the servers at a later time, select Activate in the list.

2. Click the Update button.

The domain status for the domains that you inactivate changes from Active to Inactive. In addition, in the Dispatcher Status section, the dispatcher status of all processes associated with the domains changes from active (ACT) to cleanup (CLNUP). Click the Refresh button until the dispatcher status changes to inactive (INACT).

If you inactivated all domains, a Force Reset button appears under the Update button. The Force Reset button enables you to force the dispatcher status to change from cleanup to inactive.

Changing Dispatcher Status for Processes

The Force Reset button appears only when you change the domain status for all domains on all machines by selecting the All Domains Inactive check box.

To change dispatcher status for all processes on all machines from cleanup to inactive:

1. Click the Force Reset button.

2. Click Update.

Setting Domain Grace Periods

The time that appears in the Grace Period column indicates when the cleanup process ends. The time equals the system time and the cleanup time interval that you enter.

To set one grace period to apply to domains on all machines, locate the Grace Period for all Domains field in the Domain Criteria section and enter the number of minutes for the grace period. Click Update.

To set grace periods for individual domains, enter the number of minutes for the grace period for each domain. Click Update.

A grace period that you set for an individual domain takes precedence over the setting for all groups.

The grace period setting for all domains is a convenient way to set a grace period for all dispatchers in all the domains. You can set a grace period of all domains at the top of the page and then press the Tab key to access individual domains and override the group setting.

Setting Up Domain Failover

This section discusses domain failover and configuration of domain failover.

To set up domain failover, you use the Failover Configuration page in the Integration Broker Monitor. To access the page, select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Domain Status. Then, click the Set Up Failover link.

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, message 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 messages 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 groups.

Note. Channel sets within groups must be identical; channel sets between groups must be unique.

The preceding example of the Failover Configuration page 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, HLAM032002, is the first back-up domain as indicated by the failover priority value 1; the second domain in the list, HLAM042503, 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 HLAM072500.

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

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 Integration Broker Monitor.

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

See Implementing Master-Slave Dispatchers.

Setting Up Failover on Domains

To set up domain failover:

1. Access the Failover Configure page.

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

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

• Check the Enbale Failover box.

• Check the Dynamic Slave Option box.

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

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

Modifying Failover Priorities

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.

Checking Channel Set Validity

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

Viewing Channels Assigned to Failover Groups

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

Viewing Messaging System Performance Statistics

This section provides an overview of messaging system performance statistics and discusses how to:

• Enable the messaging system performance statistics feature.

• Filter statistics data.

• View inbound asynchronous post statistics.

• View broker handler statistics.

• View subscription contract handler statistics.

• View publication contract handler statistics.

• View inbound synchronous message statistics.

• View outbound synchronous message statistics.

• View local synchronous message statistics.

Understanding Messaging System Performance Statistics

Integration Broker Monitor provides a Statistics page that enables you to view performance statistics for asynchronous and synchronous messages that flow through the messaging system.

To access the Statistics page, select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Statistics.

Integration Broker Monitor provides performance statistics for the flow of asynchronous messages through the pub/sub system. Statistics are captured for the flow of messages through the following pub/sub components:

In addition, Integration Broker Monitor provides performance statistics for the following synchronous transaction types.

In the case of asynchronous message flow through the publication contract handler and outbound synchronous transactions, you can capture statistics about performance on remote PeopleSoft systems. You do not need to perform any setup tasks in the integrationGateway.properties file or in the PSADMIN utility to capture performance statistics on the remote PeopleSoft system. The sending PeopleSoft system includes an identifier in the message request that prompts the remote PeopleSoft system for performance information. This information is returned as part of the response message.

You can view messaging system performance statistics in numeric or graphical format.

By default, the statistics appear in numeric format on tabbed pages.

You can select to view the statistics in graphical bar chart or pie chart format from any of the pages by using the View Bar Chart and View Pie Chart buttons. When you click either button, another page opens and displays the statistics in the graphical format. To return to the numeric format view of the data, click the Return button at the bottom of the page.

Note. Data displayed in bar chart and pie chart formats are averages.

The following example shows the outbound synchronous performance statistics in bar chart format:

The following example shows the same statistics in pie chart format:

Common Elements Used in This Section

Note. All times shown on the Statistics page are in milliseconds.

Enabling the Messaging System Performance Statistics Feature

To view message system performance information, you enable the statistics feature on the application server through the PSADMIN utility and on the integration gateway through the integrationGateway.properties file. If you do not enable the statistics feature on the application server, the system will not capture any messaging system information.

If you enable the feature only on the application server and not on the integration gateway, the system captures statistics only for activity on the application server and does not capture any information for activity on the integration gateway.

Note. It is recommended that you enable the statistics feature on both the application server and on the integration gateway.

To enable the statistics feature on the application server:

1. Access the PSADMIN utility.

2. Locate the PeopleSoft Domain Administration section and select the following option:

   Do you want to configure this domain?

3. Enter Y for yes to shut down the domain.

4. At the Do you want to change any config values? prompt, enter Y.

5. Press the Enter key to move through the list of options, and accept all existing values until you locate the following section:

   Values for Config Section - Integration Broker.

6. Change the IB Profile Information setting to Y.

7. Press the Enter key to finish moving through the lists of options.

8. At the end of the options lists, PSADMIN loads the new configuration.

9. Start up the domain.

To enable the statistics feature on the integration gateway:

1. Access the integrationGateway.properties file.

2. Locate the Profile Information section at the end of the file.

3. Set the ig.ProfileInformation property to TRUE.

4. Save the file and refresh the integration gateway.

Selecting Statistics Data to View

When you select a transaction type for which to view statistics, you can filter data by various criteria.

The following common elements are used to filter statistics data.

To view select statistics data to view:

1. Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message and click the Statistics tab. The Statistic page displays.

2. Click the link that corresponds to the transaction type for which you want to view statistics. The choices are:

   • Inbound Asynchronous Post

   • Broker Handler

   • Subscription Contract Handler

   • Publication Contract Handler

   • Inbound Synchronous

   • Outbound Synchronous

   • Local Synchronous

   The Message Search Criteria dialog box for the transaction type you selected displays.

3. Enter values in the Message Search Criteria dialog box, based on the data you want to view.

4. Click the Refresh button.

Viewing Inbound Asynchronous Post Statistics

The following table describes the fields and data that displays on the Transactions, Gateway Request Times and Application Server Times tabs on the Inbound Asynchronous Post page. This information also applies to the information that appears when you view the data in graphical format.

Viewing Broker Handler Statistics

The following table describes the fields and data that appear on the Transactions and Times tabs on the Broker Handler page. This information also applies to the information that appears when you view the data in graphical format.

Viewing Subscription Contract Handler Statistics

To view subscription contract handler statistics, click the Subscription Contract Handler link on the Statistics page. The Subscription Contract Handler page appears.

The following table describes the fields and data that appear on the Transactions and Times tabs on the Subscription Contract Handler page. This information also applies to the information that appears when you view the data in graphical format.

Viewing Publication Contract Handler Statistics

To view publication contract handler statistics, click the Publication Contract Handler link on the Statistics page. The Publication Contract Handler page appears.

The following table describes the fields and data that appear on the Transactions, Publication Contract Total, Publication Handler, Gateway, and Remote PeopleSoft System tabs on the Publication Contract Handler page.

The following table describes the average total values displayed in the Average Total Time section when you view publication contract handler statistics in graphical format. The fields in the Average Time section are described in the preceding table.

Viewing Inbound Synchronous Message Statistics

To view inbound synchronous message statistics, click the Inbound Synchronous

link on the Statistics page.

The following table describes the fields and data that appear on the Transactions, Gateway Request Times, PeopleCode Times and Application Server Times tabs on the Inbound Synchronous page. This information also applies to the information that appears when you view the data in graphical format.

Viewing Outbound Synchronous Message Statistics

To view outbound synchronous message statistics, click the Outbound Synchronous link on the Statistics page. The Outbound Synchronous page appears.

The following table describes the fields located on the Transactions, Synchronous Total, Synchronous Processing and Gateway Request Times, Remote PeopleSoft Systems and Gateway Response Times tabs on the Outbound Synchronous page.

The following table describes the average total values displayed in the Average Total Time section when you view outbound synchronous statistics in graphical (bar chart or pie chart) format. Note that the fields shown in the Average Time section are described in the previous table.

Viewing Local Synchronous Message Statistics

To view local synchronous message statistics, click the Local Synchronous link on the Statistics page. To view outbound synchronous message statistics, click the Outbound Synchronous link on the Statistics page. The Local Synchronous page displays.

The following table describes the fields located on the Transactions, Synchronous Total, Synchronous Processing, Gateway Request Times and Gateway Response tabs on the Local Synchronous page.

The following table describes the average total values displayed in the Average Total Time section when you view outbound synchronous statistics in graphical format. Note that the fields shown in the Average Time section are described in the preceding table.

Running Message Queries

Select PeopleTools, Integration Broker, Monitor Integrations, Monitor Message, Queries to access the Queries page.

When you have numerous messages, nodes, and channels it can be difficult to track all of the definitions and routings. Use this page to gather information about messaging system metadata without having to access message definitions, channel definitions, or node definitions in Application Designer.

The queries take advantage of the URL interface for PeopleSoft Query and Process Scheduler Report Manager.

Because PeopleSoft Query is involved, anyone running the queries requires the appropriate security permissions to do so.

These queries are not intended to be run every day or even on a regular basis. They are most useful for obtaining auditing information shortly after an implementation or upgrade. PeopleSoft Query enables you to view the information with Microsoft Excel.

The following table describes each query:

See Also

Enterprise PeopleTools 8.46 PeopleBook: PeopleSoft Query

Enterprise PeopleTools 8.46 PeopleBook: PeopleSoft Process Scheduler

Archiving Message Instances

This section discusses archiving message instances and retrieving archived message instances

Archiving Messages

You can archive message instances one at a time from the Message Details component or the Synchronous Details component by clicking the Archive button that appears in the Action column on either page.

Retrieving Archived Messages

You can retrieve archived message instances from the following tabs in the Monitor Message component: Overview tab, Message Instances tab, Pub Contracts tab, and Sub Contracts tab.

To retrieve archived message instances, select theArchive check box and click Refresh. Archived messages appear in the results grid. For any returned row, click the Details link to view the message header and message content.

Monitoring Asynchronous Message Details

The Message Details component enables you to gather in-depth information about a specific asynchronous message. It also enables you to perform tasks such as correct errors and resubmit messages.

This section discusses how to:

• Access the Message Details component.

• View asynchronous message properties.

• View asynchronous message errors.

• View asynchronous messages in XML format.

• View nonrepudiation information for asynchronous messages.

Accessing the Message Details Component

To access the Message Details component, use the PeopleTools menu structure and select PeopleTools, Integration Broker, Monitor Integrations, Message Details. The Message Details search page displays.

You can search for a message using the following criteria:

After you search for and select a message, the Message Detail —Message properties page appears.

Viewing Asynchronous Message Properties

Select PeopleTools, Integration Broker, Monitor Integrations, Message Details to access the Message Properties page.

The Message Properties page displays information pertaining to the message instance and all associated publication and subscription contracts.

There are three sections that appear on the Message Properties page. This section discusses the three grids and the information that appears in them. This section discusses:

• Message Instance Information section.

• Publication Contracts section.

• Subscription Contracts section.

Message Instance Information Section

The Messaging Instance Information section provides general information pertaining to a particular message to assist in troubleshooting.

The Actions column in the Message Instance section contains controls that apply to the message instance and all associated publication and subscription contracts.

Publication Contracts Section

The Actions tab reveals all the nodes subscribing to a particular message and the current status of the publication contract, as in whether the publication has been successfully posted to the subscribing node.

If you click the View XML link, a new page opens and the XML for the selected message appears. If any transformations were applied for the publication contract, the transformed XML displays. Use the View XML link in the Message Instance section to see the original XML that was received. You can edit the XML if you have the appropriate permissions, and if the message has the status of New, Error, Retry, Timeout, Edited or Cancelled.

Click the View IBInfo link to view IBInfo data for the publication contract, such as requesting node, transaction ID, content type, and so on.

See Message Statuses.

The Information tab contains the following information about the publication contract:

Subscription Contracts Section

The Actions tab reveals the status of a particular subscription contract.

If you click the View XML link, a new page opens and the XML for the selected message displays. If any transformations were applied for the Subscription Contract, the transformed XML displays. Use the View XML link in the Message Instance section to see the original XML that was received.

You can edit the XML if you have the appropriate permissions, and if the message has the status of New, Error, Retry, Timeout, Edited or Cancelled.

See Message Statuses.

The Information tab provides the following information.

Viewing Asynchronous Message Errors

The Message Errors page enables you to view any possible errors with message instances, publication contracts, and subscription contracts.

The tabs on this page let you see when an error occurred, what the error message is, and where the error occurred.

Viewing Asynchronous Messages in XML Format

The XML Message Viewer page in the Message Details component enables you to view the raw XML code. On this tab, you can locate specific sections of the XML code.

Use the Display Formatted check box to adjust how the XML appears. In most cases, displaying the message in its formatted form makes it easier to read and to locate specific values or tags.

The XML Message Viewer page also features several links.

Viewing Nonrepudiation Information for Asynchronous Messages

The Signature (NR) page of the Message Details component displays nonrepudiation information for asynchronous messages. This page appears only if a message is sent with a signature; it displays the nonrepudiation signature in XML format.

Click the Confirm button to confirm the nonrepudiation status.

Viewing Synchronous Message Details

The Synchronous Details component enables you to gather in-depth information about a specific synchronous message. It also enables you to perform tasks such as view logs and correct errors.

Accessing the Synchronous Details Component

To access the Synchronous Details component, select PeopleTools, Integration Broker, Monitor Integrations, Synchronous Details. By default, the Sync Message Detail page is active.

The following sections provide information about each page in the Synchronous Details component.

Viewing Synchronous Message Details

Select PeopleTools, Integration Broker, Monitor Integrations, Synchronous Details to access the Sync Message Detail page.

The Sync Message Detail page provides read-only information about synchronous messages in the system. It also enables you to view signature information for a message if it was processed with nonrepudiation logic.

In addition, you can use the Archive

button to archive messages.

The section discusses:

• Viewing message attributes.

• Viewing message signature information.

Viewing Message Attributes

You can view the following message attribute information on the Sync Message Detail page.

Note. For synchronous messages, you can view the full message detail in XML only if you have selected the Log Message Detail option for the transactions. To select this option, select Node Definitions, Transactions, Edit (a transaction), Transaction Detail, Message.

Viewing Message XML Content

In certain situations, the XML content of a message isn’t visible in Integration Broker Monitor. This is because of the way message data is logged. Initially, the log data (including the message XML) for any transaction is held in system memory.

With synchronous transactions, PeopleSoft Integration Broker retains the log data in memory for a longer period, to allow for certain operations to complete. The delay before you can view the XML content in the Synchronous Details component depends on several factors, including the details of the integration and whether you’re at the sending or the receiving end of the transaction. If you don’t see the message XML content right after the message was transmitted, exit the Synchronous Details component and wait for a minute, then reopen the message and check the XML view again.

Note. The synchronous message XML content won’t appear at all unless you selected Log Message Detail on the Transaction Messages page of the synchronous transaction definition.

See Configuring Transactions.

Viewing Message Signature Information

If a message is sent with a signature, a signature link appears next to the Non-Repudiation ID number. When you click the signature link, the message signature appears in XML. You can click the Confirm button to confirm the nonrepudiation status. Click the Return button to return to the Sync Message Details page.

Viewing Synchronous Message Errors

The Sync Error page in the Synchronous Details component provides read-only information about any error related to synchronous messages.

The information that appears on the page indicates the original publishing node of the message, the channel, the message name, the transaction type, and more.

Note. If you have the Synchronous Logging option set to No Logging for a synchronous message transaction, the message header and error information is displayed only if there is an error. If there is no error, no information is logged and displayed.

The tabs on this page let you view error message details such as what type of error occurred, and when and where the error occurred.

Running Batch Error Notification Processes

This section provides an overview of batch error notification and discusses how to run batch error notification programs.

Understanding Batch Error Notification

Although you can easily use the Integration Broker Monitor to scan your system for messages, that approach requires you to launch Integration Broker Monitor on a scheduled basis to search for any issues affecting the messaging system. The Error Notification component (PT_ERR_RUNCNTL) provides access to an Application Engine batch program, PT_AMM_WF, that you can schedule to run on a recurring basis.

To access the program, select PeopleTools, Integration Broker, Monitor Integrations, Error Notification.

Note. You can use PT_AMM_WF to notify users of errors relating to asynchronous messages only.

The following table describes the information for which PT_AMM_WF scans, how it notifies administrators, and what administrators should do after receiving an error notification.

Prerequisites for Using Batch Error Notification

To enable the workflow notification functionality, you need to have the following items in place within security definitions:

• Grant access to the PT_AMM_DUMMY component interface. Navigate to PeopleTools, Security, Permissions & Roles, Permission Lists, Component Interfaces.

• Assign users to the APP_MSG_ADMINISTRATOR role using PeopleTools, Security, Permissions & Roles, Roles, Members.

  PeopleSoft delivers the APP_MSG_ADMINISTRATOR role.

• Add email addresses for users assigned to the APP_MSG_ADMINISTRATOR role to their user profiles so that they can receive the notification.

  To complete this task, select PeopleTools, Security, User Profiles, User Profiles, Edit Email Addresses

See Also

Enterprise PeopleTools 8.46 PeopleBook: Security Administration

Creating Static Error Notification Lists

By default, error notifications are sent to all users who can monitor the message channel; these are users assigned to the Query role. However, you can send error notifications to a static list of users that belong to the APP_MSG_ADMINISTRATOR role. To do so you must turn off the Use Query to Route Workflow option for the APP_MSG_ADMINISTRATOR role, and assign specific users to the role.

To view users assigned to the APP_MSGADMINISTRATOR role, run the _ROLE_APP_MSG_ADMINISTRATOR query.

To create a static error notification list:

1. Turn off the User Query to Route Workflow option.

   1. Select PeopleTools, Security, Permissions & Roles, Roles.

   2. Select and open the APP_MSG_ADMINISTRATOR role.

   3. Click the Workflow tab.

   4. In the Workflow Routing Options box, clear the Use Query to Route Workflow option, and click Save.

2. Assign specific users to the APP_MSG_ADMINISTRATOR role.

   See Specifying User Profile Attributes.

Running Batch Error Notification

You use the Error Notification page to run the PT_AMM_WF process. To access the page, select PeopleTools, Integration Broker, Monitor Integrations, Error Notification.

To run PT_AMM_WF:

1. Select PeopleTools, Integration Broker, Monitor Integrations, Error Notification.

2. Select an existing run control ID, or add a new one using the Add button.

   The Error Notification page appears.

3. Select a process frequency.

   Options are:

   • Process Once. Select to run PT_AMM_WF manually.

   • Process Always. Select to run PT_AMM_WF constantly.

   • Don't Run. Select to disable a recurring PT_AMM_WF run.

4. Add a request ID and description.

   These attributes uniquely identify a run control. You only see the IDs when you have a list of run controls.

5. In the URL field, enter the PeopleSoft Pure Internet Architecture URL to provide in the email error notification. Users use the URL to link to the error.

   The URL of the current web server displays in this field by default.

6. ClickRun.

7. Click OK on the Process Scheduler Request page to submit the process.

Running Batch Message Archiving Processes

For performance and general maintenance reasons, you may want to archive older messages to clear space on your live messaging tables.

The PeopleSoft system provides an Application Engine program that scans all of the messaging tables in the system for message archiving purposes. You use the Archive Messages component (RUN_APMSGARCH) to access the program.

You use the Run Archive page to invoke the archive process. To access the page, select PeopleTools, Integration Broker, Monitor Integrations, Archive Messages.

You can use the Run Archive page to archive all messages with a status of Done or Cancel. Or you can archive messages based on their status, their age, or a combination of the two. For example, you can choose to archive messages with a status of Done that have been in the messaging system for more than 14 days.

Before you run a batch message archive process, inactivate the pub/sub server domain. Then, after you run the process, reactive the pub/sub server domain.

See Working with Pub/Sub Server Domains.

To run the batch message archiving process:

1. Select PeopleTools, Integration Broker, Monitor Integrations, Archive Messages.

2. Select an existing run control ID, or add a new one.

   The Run Archive page appears.

3. Select the messages to archive

   Archive All Messages	Select this check box to archive all messages in the messaging system with a status of Done or Cancel, regardless of how long they have been in the messaging system.
   Done	Select to archive messages in the messaging system with a status of Done.
   Cancel	Select to archive only those messages in the messaging system with a status of Cancel.
   Older Than	Enter a numeric value between 1 and 999. Do not enter 0 or a decimal value. Messages older, in days, than the value that you enter will be archived. This option archives messages based on days. If the date is August 15, 2004, messages dated August 13, 2004 and earlier are archived.

4. Click the Run button.

   The Process Schedule Request page appears.

5. Make the appropriate selections, and click OK.

Note. Using APPMSGARCH to archive message data is the batch approach. You can also archive individual messages online using the Integration Broker Monitor.

See Also

Using Process Monitor

Using Report Manager

Purging Messaging Tables

The PeopleSoft system provides a collection of Data Mover scripts that you can run to purge the messaging tables within a database. These scripts reside in the PS_HOME\scripts directory on your file server. The following table describes the purpose of each script.

Warning! Shut down the application server before running any of the Data Mover scripts described in this section.

Using the Message Monitor Component Interface

Integration Broker Monitor includes a collection of inquiry methods that you can access with a component interface.

Use the MSGSTATUSSUMMARY component interface to extract information from Integration Broker Monitor. The output of the component interface reveals the amount of contracts that are in the queue. The contracts appear grouped by status and message or grouped by status and channel.

You can use the following user-defined methods to extract information:

• FillPubConByMsg()

• FillPubConByChannel()

• FillSubConByMsg()

• FillSubConByChannel()

The following example shows ASP code that accesses the MSGSTATUSSUMMARY component interface with COM.

'Create a peoplesoft session
Set oSession = server.CreateObject ("PeopleSoft.Session")
nStatus = oSession.Connect(1, oConnectString, oUserName, oPassword,0)

'Get the skeleton of the APPMSGMON CI
Set oCI = oSession.GetCompIntfc("MSGSTATUSSUMMARY")

'get an instance of the CI
nStatus = oCI.Get()
'execute the method to fill the collection

If oChoice = 1 then
   nStatus = oCI.FillPubConByChannel()
   'Set oRows to the properties collection
   Set oRows = oCI.PubConByChannel
End If

If oChoice = 2 then
   nStatus = oCI.FillPubConByMsg()
   'Set oRows to the properties collection
   Set oRows = oCI.PubConBymsg
End If

If oChoice = 3 then
   nStatus = oCI.FillSubConByChannel()
   'Set oRows to the properties collection
   Set oRows = oCI.SubConByChannel
End If

If oChoice = 4 then
   nStatus = oCI.FillSubConByMsg()
   'Set oRows to the properties collection
   Set oRows = oCI.SubConByMsg
End If

See Also

Introducing Component Interfaces

Using PeopleCode to Read and Write Errors to the Asynchronous Messaging Error Queue

PeopleSoft provides the following two methods to read and write errors to the asynchronous messaging error queue:

See Also

PeopleCode API Reference Preface