Appendix: Integrating the Case with Third-Party Systems

This appendix provides an overview of the case enterprise integration point (EIP) and discusses:

• Case EIP functionality.

• Case EIP implementation.

Understanding the Case EIP

The Case EIP integrates the PeopleSoft CRM case with third-party systems. The case EIP is developed generically for PeopleSoft Support, HelpDesk, HelpDesk for Human Resources, and all PeopleSoft CRM verticals. The case EIP allows you to:

• Create a case from a third-party system.

• Update a case from a third-party system.

• Request case information from a third-party system.

This appendix serves as a guide for technical users, installers, system administrators, and programmers who implement, maintain, or develop Case EIP.

Defining Case EIP Functionality

In this section, we discuss:

• Assumptions about the case EIP.

• Case EIP functionality.

• Delivered EIPs.

• Technical process flows for the EIPs.

• Error Handling.

Assumptions About the Case EIP

When considering the case EIP, you must consider the following:

• To create a support case, the following customer information fields must be provided: customer BO ID, customer role type ID, contact BO ID.

• The third-party system needs to send the appropriate business unit, vertical and market values in the request, unless these values can be defaulted from user reference.

• The case EIP is developed using PeopleTools 8.4 integration broker technology.

• There is no bulk loading using the case EIP. The case EIP feature is intended to automatically create and update cases from third-party systems, not for data-conversion purposes.

• The case EIP and related case component interfaces are meant for the agent facing case, not for self-service.

• When creating a note for a case using the case EIP, the customer, contact and employee information is left as blank. The case EIP cannot create a note for a different customer, contact or employee.

• A case may use attributes. An attribute can be of any data type (string, number, date, etc.). Different data types are stored in the matching data type field in the request message. It is the responsibility of the third-party system to provide the correct data format for attributes when creating attributes for a case.

• The case component can be configured to enable or disable functionality and hide or unhide fields on the case page. The case component is rendered based on the display template. When customers send request to create a case, it is assumed that they will not send information that has been disabled or hidden. The Case EIP will not do additional validation that based on configuration settings.

  See Configuring Display Templates.

Case EIP Functionality

The case EIP provides a bi-directional EIP in CRM for PeopleSoft Support, HelpDesk, HelpDesk for Human Resources, and all PeopleSoft CRM verticals. It provides a transactional framework that enables your call center to send and receive case information to and from any third-party applications.

This diagram illustrates the case EIP process flow:

Case EIP process flow

Delivered EIPs

The following EIPs, as shown in the previous diagram, are provided:

• EIP #1 - Case Synchronous EIP.

• EIP #2 - Case Asynchronous EIP.

• EIP #3 - Request Case Information EIP (Synchronous).

Note. If the request contains a case ID, a new case will not be created. The existing CRM case will be updated with the pertinent information supplied in the request. If the case ID passed in is invalid, no case will be updated, and an error message will be sent back.

Note. Tip: When you create a case, make sure the value of the CASE_IDfield in the request message is empty or 0. When you update a case, make sure the CASE_ID value is a valid value that exists in CRM RC_CASE table.

Case Synchronous EIP

The third-party application sends a request to CRM to create or update a case, and waits for the response. Once the case is processed in CRM, confirmation information is sent back to third-party.

This EIP contains two messages:

• RC_CASE_REQUEST_SYNC —Inbound synchronous request message.

• RC_CASE_RESPONSE_SYNC —Outbound synchronous response message.

The processing details are as follows: when a request message is received, the —on request event— calls an appropriate case component interface (CI) to process information from the request message, and saves into the case component. A response message is sent back to the third-party system with confirmation information. The response message may contain information that CRM populates, such as case id, assigned provider group and agent.

Since the third-party system will be waiting for the response from CRM, only one case will be processed per message.

Case Asynchronous EIP

The third-party system sends a request to create or update a case, and it is not waiting for the response. Once the case is created or updated, CRM will publish confirmation information back to third-party.

It contains two messages:

• RC_CASE_REQUEST_ASYNC — Inbound asynchronous message.

• RC_CASE_RESPONSE_ASYNC — Outbound asynchronous message.

The processing details are as follows: when CRM receives the request, subscription people code will call the appropriate case CI to create or update a case, and publish case information back to third-party.

Since the third-party system is not waiting for the response from CRM, the request message may include information from multiple cases in one message. CRM will process them one by one. A commit will be issued at end of each successful case.

Request Case Information EIP (Synchronous)

The third-party system sends a request to CRM to find case information. The request may contain multiple cases. CRM process the request, and send the case(s) information back to the third-party system.

It contains two messages:

• RC_CASE_INQUIRY_REQ_SYNC — Inbound synchronous request message

• RC_CASE_INQUIRY_RESP_SYNC — Outbound synchronous response message

The processing details are as follows: the request message may have one or more Case IDs, the —on request event—will be triggered, and CRM will process the rowset of the message to populate case information, one by one. A direct SQL query will be used instead of CI.

Technical Process Flows

The logic of EIP #1 and #2 are the same except they way in which they are initiated. EIP #1 is triggered from an OnRequest event. A sync response message is generated and returned to the to third-party system. EIP #2 is triggered from message subscription PeopleCode. A response message is published for the third-party application. EIP #1 and #2 share the same PeopleCode function, ProcessCaseEIP defined in the FUNCLIB_RC_EIP.CASE_EIP field formula.

The following diagram illustrates the technical process flow for both EIP #1 and EIP #2.

Process Flow Diagram for EIP #1 and EIP #2

The following numbered list indicates where you are in the process flow diagram:

1. The third-party sends an XML request to CRM by way of the integration gateway.

3. If integration broker (IB) does not recognize the format, the message will be trapped in integration broker. The process will fail. This is standard integration broker functionality.

See PeopleSoft Integration Broker

4. OPRID is required. It is used to validate whether the user has access to the requested case. Once the user passes security checking, a case will be created or updated through integration broker. The integration broker user ID will be used to create or update a case. This is the user ID that is used to start application server.

5. If the user passed the security check, a session is obtained for component interface processing.

6. When creating a case, BUSINESS_UNIT is required. The system will automatically assign the next new CASE_ID. If BUSINESS_UNIT is not supplied when creating a case, CRM will use the default business unit from user preference. When updating a case, only CASE_ID is required since it is unique identifier.

7. Based on the keys set, the system decides whether to insert or update a case. When there is no Case ID provided, CRM will create a case by calling the create() method of CI. When the Case ID is provided, CRM will check whether the Case ID exists in CRM. If it exists, the case will be updated by calling the get() method; otherwise, no case processing will be done. A response message will be generated with CASE_EIP_STATUS = 1 (failed) and CASE_EIP_ERROR_MSG —Update failed. Case 123 does not exist in CRM.?

PeopleCode function IsCaseExist in FUNCLIB_RC_EIP CASE_ID FieldFormula checks if the case exists.

8. If the create() or get() method fails, the error message will be generated in RC_CASE_EIP_ERR for the response message. The CI will be canceled to reset the instance (process 11), and the response message with the error message will be sent back to third-party (process 12).

9. Once the create() or get() method passes successfully, CRM will set the CI properties as supplied in the request message.

When the third-party application sends a request to create a support case, customer and contact information is required.

For customer information, the third-party application can either provide CUST_ID or BO_ID_CUST. If BO_ID_CUST is provided, CRM will use it directly to create a case. Conversely, if only CUST_ID is provided, CRM will use the BC table to derive BO_ID_CUST in order to create a case.

The function to get BO_ID_CUST based on CUST_ID is the PeopleCode Function GetCustBObyID in FUNCLIB_RC_EIP.CASE_ID FieldFormula.

For contact information, the third-party application can either provide PERSON_ID or BO_ID_CONTACT. When BO_ID_CONTACT is provided, CRM will use it directly; otherwise, CONTACT_PERSON_ID will be used to derive BO_ID_CONTACT from the RD_PERSON table.

The function to get BO_ID_CONTACT based on PERSON_ID is the PeopleCode Function GetPersonBObyID in FUNCLIB_RC_EIP.CASE_ID FieldFormula.

HelpDesk and HelpDesk for Human Resources Cases Only

When the third-party application sends a request to create a helpdesk case, employee information must be provided. The third-party application must supply the EMPLID, and CRM will use it to derive appropriate BO_ID_CUST with ROLE_TYPE_ID_CUST in order to create a case. BO_ID_CUST and ROLE_TYPE_ID_CUST need to be populated internally for a case.

Note. Tip: When creating a support case for customer, make sure BO_ID_CUST (or CUST_ID), ROLE_TYPE_ID_CUST, BO_ID_CONTACT (or CONTACT_PERSON_ID), ROLE_TYPE_ID_CNTCT is provided; when creating a PeopleSoft HelpDesk case for an employee, make sure the EMPLID is provided.

15. If the setting of a CI property for a field fails, an error message will be trapped in the &PSMessage object with information on which field causes an error.

The following diagram illustrates the technical process flow for EIP #3.

Process Flow Diagram for EIP #3

1. The third-party application sends an XML request to CRM by way of the integration gateway.

2. If the integration broker (IB) does not recognize the format, it will be trapped in integration broker. Case process will fail.

See PeopleSoft Integration Broker

3. When message passed in from integration broker, people code process will begin. CRM will check if the case ID exists in CRM. If the case does not exist in CRM, a response message with error message will be sent back (process 5).

4. If the case exists in CRM, market and vertical information will be gathered, and CRM will further check if the user has access to case component based on market and vertical. If user does not have access, a response message will be sent back right away with error message of access denied (process 5).

Function to check access permission: IsUserAuthorized in FUNCLIB_RC_EIP.CASE_ID FieldFormula.

5. Once the user passed the security check, a direct SQL query will be executed to get all case related information and send back to third-party (process 8).

Error Handling

When a required field contains an invalid value in request message, or the save event fails, the process will fail. The request message will be copied over to response message, and the response message will be sent back to third-party with error message.

When a non-required field contains an invalid value, that field will be ignored or and case processing will continue. A warning message will be sent back.

Here are some tips:

• Always check fields CASE_EIP_STATUS and CASE_EIP_GEN_MSG first in the response message. When the status is 0 or 2, the response message will contain case information stored in CRM system. When status is 1, i.e. when case is failed, nothing is saved in the CRM system, and the response message will contain a copy of the request information, not the case information stored in CRM. This is provided to aid in error handling.

• When CASE_EIP_STATUS fails or there is a warning warning, a detailed error or warning message will be logged in the rowset RC_CASE_EIP_ERR of the response message.

Implementing Case EIP

In this section, we discuss:

• Code Processing for Case EIP.

• Setup configuration.

• Case EIP setup.

Code Processing for Case EIP

For Case EIP #1 (Case Synchronous Message), the entry point is in Message RC_CASE_REQUEST_SYNC OnRequest Peoplecode. It calls ProcessCaseEIP function in FUNCLIB_RC_EIP.CASE_EIP FieldFormula.

For Case EIP #2 (Case Asynchronous Message), the entry point is in Message RC_CASE_REQUEST_ASYNC, Message Subscriptions CaseRequestAsync peoplecode, it calls the same ProcessCaseEIP function as EIP #1.

For Case EIP #3 (Request Case Synchronous Message), the entry point is in Message RC_CASE_INQUIRY_REQ_SYNC OnRequest Peoplecode. It calls ProcessCaseInquiry function in FUNCLIB_RC_EIP.CASE_EIP FieldFormula.

Setup Configuration

There are three setup options for case EIP:

• Number of notes for a case

• Default value for Source EIP

Number of Notes for a Case

The Max # of Notes in Response EIP field indicates most number of notes to return in the request EIP. The case component can contain an unlimited number of notes. This will impact case EIP performance when trying to process hundreds, thousands notes for a case. Based on business requirement, customer can set the upper limit number for case EIP. Note, This is only applied to response message. Request message will process all notes that third-party sends.

For instance, the customer sets the default number of notes for response message as 5. When request message contains more then 5 notes, all the notes will be processed and saved into the case. When a case contains more than 5 notes, and third-party is requiring the case information, then only the 5 most recent notes will be returned in the response message.

This screenshot illustrates the Max # of Notes in Response EIP field on the Call Center Definition – Options page.

Default Value for Source EIP

Customer can define the source value to use when creating a case via the Case EIP. It can be a different source value from that of cases created on line.

Note. These two options are all driven by business unit.

Case EIP Setup

Activate the following messages:

• RC_CASE_REQUEST_SYNC

• RC_CASE_RESPONSE_SYNC

• RC_CASE_REQUEST_ASYNC

• RC_CASE_RESPONSE_ASYNC

• RC_CASE_INQUIRY_REQ_SYNC

• RC_CASE_INQUIRY_RESP_SYNC

As delivered, PeopleSoft EIP application messages are inactive. In both your PeopleSoft CRM and your third-party application, activate the required application messages, activate the message subscription PeopleCode, set the associated message channel to run mode, configure an existing message node or define a new message node, and define asynchronous or synchronous transactions on the message node.

See Application Messages.

See Also

PeopleSoft Integration Tools and Utilities

PeopleSoft Integration Broker