PeopleSoft MCF Architecture

The REN server (the PSRENSRV process) is essential to the framework architecture. MCF events are sent to REN servers, which then deliver them to recipients of those topics. The REN server is a modified web server using the HTTP 1.0 or HTTP 1.1 communications protocol. Communication with server processes and MCF browser windows is bidirectional, because the browser windows maintain persistent connections to the REN server. Events can be sent proactively to browser windows without polling or page refreshes. To provide a secure channel of communication to overcome concerns from PeopleSoft customers about sensitive data and its security, the REN server can be Secure Sockets Layer (SSL)-enabled. An SSL-enabled REN server provides secure communication that encrypts and provides client and server authentication.

Applications send interaction and action requests (tasks) received from the supported communication channels to logical queues. The REN server notifies the universal queue server (the PSUQSRV process) responsible for that queue that a new task has arrived. Tasks are queued in order of priority until they can be assigned to an available agent qualified to respond to the task, at which time the queue server sends an assignment notification to the user’s MultiChannel Console through the REN server.

The queue server routes work requests (tasks) to users based upon a set of configurable policy properties that define which agents can handle what types of tasks and when the tasks can be assigned. The queue server manages state information about the current status of active agents and active tasks.

The MCF log server logs MCF events and chat content to the database. You configure logging levels on the MCF administration pages.

Image: MCF chat architecture and flow

The following diagram illustrates the architecture of MCF chat and the flow of a chat session.

When a customer clicks the Help button on an application page:

1. InitChat() passes the following parameters to the application server:

   • Queue number.

   • Priority override.

   • Context page URL.

   • Query.

     See InitChat.

2. The application server posts to the REN server to notify the queue server that a customer chat is waiting.

   The application server then returns the name and port of the REN server and the iScript to build the customer chat window.

3. The customer chat window appears and communicates with the REN server to receive all events on that chat topic.

4. The REN server notifies the queue server that a customer chat is waiting.

   The queue server determines the appropriate agent according to workload, cost, agent availability, skill level, and language.

5. The queue server tells the REN server to notify the agent that the agent has been assigned a chat.

6. The REN server notifies the agent from the MultiChannel Console that the agent has been assigned a chat.

7. The agent, from the MultiChannel Console, notifies the REN server to notify the queue server that the agent has accepted the task.

8. The REN server notifies the queue that the agent has accepted the task.

9. The MultiChannel Console displays an agent chat window.

   The agent responds to inquiry.

10. Agent to customer two-way communication is mediated by the REN server.

11. If the agent chooses to grab a URL, the Grab button invokes the application URL wizard.

12. If the agent chooses to push a URL, the Push button invokes a pagelet (labeled with an A in the diagram) to push a selected URL through the REN server (labeled with a B in the diagram) and customer chat window (labeled with a C in the diagram) to a new browser window.

The entire chat session can be logged through the MCF log server (labeled with a dotted line in the preceding diagram).

Image: MCF email architecture and flow

This diagram illustrates the architecture of MCF email and the flow of email processing.

When a customer sends an email:

1. A PeopleSoft Application Engine program uses the MCF email application package classes and PeopleCode built-in functions to save and enqueue email in a database.

2. The PeopleSoft Application Engine program notifies the REN server that email has been enqueued.

3. The REN server notifies the queue server of the waiting email.

4. The queue server retrieves email information required to determine appropriate routing from the database.

   The queue server determines the appropriate agent to handle each email according to workload, cost, agent availability, skill level, and language.

5. The queue server tells the REN server to notify the agent that the agent has been assigned an email.

6. The REN server notifies the agent from the MultiChannel Console that the agent has been assigned an email.

7. The agent, from the MultiChannel Console, notifies the REN server to notify the queue server that the agent has accepted the task.

8. The REN server notifies the queue that the agent has accepted the task.

9. The MultiChannel Console displays an agent email window, as determined by the application developer.

   The agent responds to the email.

10. The agent's resolution of the task is communicated back to the REN server by either the Done or Forward button.

Email events can be logged to a database by the MCF log server.