Communication with CX and TE
In most cases when JICS communicates with CX and TE systems, it does so using web services. Specifically, JICS connects to a web server associated with the ERP system, and that server processes each submission or request using the appropriate web service.
For certain types of interactions between JICS and the ERP database, the system may rely on COM- based plug-ins instead of web services. This strategy is being phased out and is not covered by this document.
You can think about the web services used by CX and TE in a few different ways. They can be classified by what they do (their function) or by what language they were written in (their structure).
Function
Each of the various web services has a different function. For example, there is one service that retrieves data about General Ledger account codes, another service that retrieves data about applicants’ test scores, and so forth. By this measure, a system that has every CRM installed will have roughly 200 different web services. Each of these services has a “name” that roughly communicates its purposes (such as GetValidAccountCodes or GetCandidateTestScores). Each service also has a GUID known as its WebServiceURLID.
Structure
The web services can be written in one of the following:
Perl (for CX)
JSP (for TE)
Java (for either CX or TE)
Typically, a site will include a Perl or JSP web service to cover every type of function. However, in some cases, the ERP system may have been upgraded to include Java web services that are intended to supersede the corresponding Perl or JSP service. It is also permissible to build a custom Java web service to replace any other service in the system.
Perl and JSP services typically require no maintenance— they are installed with your ERP system, and JICS knows to look for them. However, if the ERP system has recently been upgraded to include any Java web services, or if you have added a custom Java service, you must update the JICS database to reference these. Otherwise, JICS will use the Perl or JSP web service that exists for that function.
When a user in JICS requests information that must be derived from the ERP database, JICS begins the process of retrieving it by connecting to the appropriate web server via a specific URL. JICS stores hundreds of different URLs for this purpose, and the system must use the correct one in order to retrieve the appropriate data.
Three tables in the JICS database that store information related to these URLs are described in the following table.
Table name | Description |
|---|---|
FWK_ConfigSettings | This table contains a URL that is used as the first part of any URL that will call a Perl or JSP web service. A pathname must be added to complete the URL. |
COM_ERPWebServiceURL | This table contains the pathname—the latter portion of the URL—that will call each Perl or JSP web service. This table also stores the “name” of the web service and its WebServiceURLID. |
COM_ERPWebServiceOverride | This table stores full URLs that are used to call Java web services. Each record in this table is also identified by a WebServiceURLID that identifies the function this URL is associated with. If any WebServiceURLID is found in this table, the Java service will be used and the corresponding Perl/JSP service ignored. |
FWK_ConfigSettings
The FWK_ConfigSettings table contains dozens of records that relate to the ERP system, security, and other aspects of your JICS installation. Of these, there are three records that relate to the processes described in this chapter. They include:
The record with ERPWebServiceURL in the Key column. This record contains the value (in the Value column) that constitutes the first part of the URL used to execute a Perl or JSP web service. There is no default value for this field, but your system probably contains a value that was manually set by the installation team when JICS was installed. If appropriate, you can change it.
The record with ERPWebServiceDebugXML in the Key column. This record determines whether debugging is turned on. (It is turned on when the Value column is set to true). In general, this should not be set to true unless you are actively debugging an issue. The default value is false.
The record with ERPWebServiceDebugXMLOutputPath in the Key column. This record determines, through the value in the Value column, the location to which debugging output will be written. The default is: c:/temp/webservicelog.txt.
Any of these values can be modified either through a direct update to the database or through JICS. For further guidance, see Modifying the Web Services Settings.
COM_ERPWebServiceURL
The COM_WebServiceURLID table contains pathnames—the latter portions of the URLs that call Perl and JSP web services. This table is populated when JICS is installed with default data, some of which may be updated when you upgrade JICS. None of the data in this table should be customized.
For these records to be useful, the appropriate Perl or JSP web services must be installed in the corresponding locations. This should have happened when your ERP system was installed and configured.
The columns in this table represent the following information:
A string that roughly communicates the purpose of the service (CRMSubType)—its “name.”
The module it is used by (CRMType).
The ERP system that uses it—either CX or TE (ERP).
The pathname that represents where the service is installed. This value also serves as the latter part of the URL used to activate the web service (URL).
A GUID (WebServiceURLID).
COM_ERPWebServiceOverride
The COM_ERPWebServiceOverride table contains URLs that call Java web services. These are always full URLs. This table is not automatically populated by JICS. It must be manually populated by an administrator with records that match the locations of your Java web services.
The columns in this table represent the following information:
A GUID that must match one of the WebServiceURLID values in the COM_WebServiceURLID table (WebServiceURLID).
The full URL used to activate the web service (URL).
A GUID that will be automatically generated when a row is added to this table (WebServiceOverrideID).
To better understand how the pieces fit together, consider how the system would respond in the case of a user requesting a specific General Ledger account code from the GL Account Lookup feature, which is part of CRM Staff:
An employee requests an account code using the standard search form available in the feature. To obtain this information, JICS knows that it must use the web service named GetValidAccountCodes—but it does not yet know the WebServiceURLID of the service, whether the system will be using a Perl/JSP or Java service, or what URL will be needed.
JICS looks to the COM_ERPWebServiceURL table to obtain the WebServiceURLID of the service associated with the name GetValidAccountCodes.
JICS checks the COM_ERPWebServiceOverride table to see whether it contains a record that uses the same GUID as the one identified by the WebServiceURLID obtained in step 2. If there is a record in that table, JICS retrieves and uses the URL contained in that record.
In response, the web server executes the appropriate Java web service and returns the needed data. In this scenario, the process ends at this point.
If the COM_ERPWebServiceOverride table does not contain a record associated with the appropriate WebServiceURLID, the system uses the following two elements to piece together a URL that will execute the appropriate Perl or JSP web service:
The first part of the URL is derived from the FWK_ConfigSettings table. Specifically, the system uses the value stored in the Value column of the record where the Key is ERPWebServiceURL.
The second part of the URL is derived from the COM_ERPWebServiceURL table. The system uses the value stored in the URL column of the record where the WebServiceURLID matches the one retrieved in step 2.