Third Party Vendor Requirements and Readiness

Vendor Requirements Overview

The creation of this document was born out of the need to create a standard that all consumers should abide by. Its purpose is to prepare vendors to function within the boundaries of the Jack Henry integration environment. The requirements are simple but are designed to set certain technical expectations, enhance ease of Support from all parties and allow consumers to be prepared/flexible for changes that are not considered breaking changes. Each requirement was added to address a shortcoming or issue previous consumers dealt with that created a roadblock either during development or production implementation. This document is split into two sections to allow for development with SOAP or REST-Legacy.

Expectations

Third Party Vendors are expected to plan for the tested topics section when developing applications that will use the Jack Henry environments. At the end of your development life cycle before deployment of the consuming application, a Vendor Readiness Test (VRT) will be administered by Developer Relations personnel to gauge the application and ensure proper steps and development practices have been followed. The application presented during the test should be in a completed stage and ready for implementation in a bank’s environment.

Failure to meet these requirements can result in a delay of access to a bank’s environments until these requirements have been met. This test will be performed on a one-on-one basis.

Requesting

You can request the VRT at any time after you have completed your development efforts by submitting a case via the Vendor/Partner Portal. The test is self serve and once the request is received, an engineer will setup the test and provide scripts to follow.

Results

• Pass
  • Allows the product to be installed and supported for production locations.
• Fail
  • Prevents the installation at production locations. Retests may be rescheduled for the next business day based on availability. Failure to pass the test after 3 retests will result in a 1-week delay before further retests will be given.

Vendor Requirement Details: SOAP

Requirements

The following Items are required for successful passing of the VRT when developing with JH SOAP XML.

Soft Code Values

Required jXchangeHdr Elements Using GUID Values

With SOAP APIs the jXLogTrackingId should be provided with a unique GUID value with each call. As part of the Vendor Readiness Test, we will be ensuring that a unique value is presented.

Schema Validation

All consumers are required to meet schema validation. Schema validation is the verification that the operations inside the SOAP Body match the contract created by Jack Henry in the XSD documents. It should be noted again, that the VER_x tags are required in your request to meet schema.

Error Handling: Provider, Integration Layer, and Communications

Demonstrate the ability to identify errors, manage each type and interpret their meaning. Vendors should have basic familiarity with errors presented by Jack Henry providers, integration layer environment and generic XML errors. Below are some examples of each type.

<FaultRecInfoArray>
<FaultMsgRec>
 <ErrCode>400028</ErrCode>
 <ErrCat>Error</ErrCat>
 <ErrDesc>Customer not found</ErrDesc>
 <ErrElem>CustId</ErrElem>
 <ErrElemVal>VAX0089</ErrElemVal>
 <ErrLoc>CFCUSTINQ</ErrLoc>
 </FaultMsgRec>
</FaultRecInfoArray>

 <s:Fault>
 <faultcode
 xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-wssecurity-secext-1.0.xsd">a:FailedAuthentication</faultcode>
 <faultstring xml:lang="en-US">Access is 
denied.</faultstring>
 </s:Fault>

 <FaultRecInfoArray>
 <FaultMsgRec>
 <ErrCode>100</ErrCode>
 <ErrCat>Error</ErrCat>
 <ErrDesc>No connection could be made because the 
target machine actively refused it 
172.16.4.10:40200</ErrDesc>
 </FaultMsgRec>
 </FaultRecInfoArray>
 </HdrFault>

Produce application Request/Response XML log

Ability to provide the raw request and response XML. A key component for troubleshooting is the ability of the consumer to produce a properly formatted XML log for individual operation request/response upon request by an institution or Support.

Vendor Requirement Details: REST-Legacy

Requirements

The following Items are required for successful passing of the VRT when developing with JH REST-Legacy JSON.

Soft Code Values

The following components should be easily modified and not hard coded. Hard coded means an application must be modified, recompiled, and redeployed to modify any value.

Required Header Keys Using GUID Values

With REST-Legacy the X-RequestId requires a unique GUID value to be presented with each call. As part of the Vendor Readiness Test, we will be ensuring that a unique value is presented.

Schema Validation

All vendors are required to meet schema validation. Schema validation is the verification that the operations inside the SOAP Body match the contract created by JHA in the XSD documents. It should be noted again, that the “VER_X” tags are required in your request to meet schema.

Error Handling: Provider, Integration Layer, and Communications

Demonstrate the ability to identify errors, manage each type and interpret their meaning. Vendors should have basic familiarity with errors presented by JH providers, integration layer environment and generic errors. Below are some examples of each type.

{
 "ResponseCode": "s:Client",
 "Description": "Unable to successfully complete 
requested action. See detail section for more information 
in the standard jXchange fault format.",
 "MessageSource": "Service Gateway",
 "Details": [
 {
 "Code": "400028",
 "Category": "Error",
 "Description": "Customer not found",
 "Element": "CustId",
 "ElementValue": "VAX0089",
 "Location": "CFCUSTINQ"
 }
 ]
}

{
 "ResponseCode": 401,
 "Description": "Access denied",
 "MessageSource": "",
 "Details": [
 {
 "Code": 401,
 "Category": "Error",
 "Description": "Access denied"
 }
 ]
}

{
 "ResponseCode": "s:Server",
 "Description": "The service is unable to properly 
report the error condition it just experienced. It is 
experiencing an internal error.",
 "MessageSource": "Service Gateway",
 "Details": [
 {
 "Code": "100",
 "Category": "Error",
 "Description": "No connection could be made 
because the target machine actively refused it 
172.16.4.10:12345",
 "Element": null,
 "ElementValue": null,
 "Location": null
 }

Produce application Request/Response JSON log

Ability to provide the raw request and response JSON code. A key component for troubleshooting is the ability of the vendor to produce a properly formatted JSON log for individual operation request/response upon request by an institution or Support.

Other Considerations

The following Items are not part of the VRT. Though they still need to be considered while developing within the Jack Henry environment.

Proper Parsing

Treat the XML or JSON as XML/JSON and interpret it with an appropriate parser instead of treating it as text or searching for strings.

Custom Elements

Each Service Gateway operation provides a means for meeting additional non-standard operation requirements accomplished through the availability of Custom/ elements in requests and responses. Each Custom/ node can contain any number of additional complex and simple hierarchical structures. Please be aware these types of elements may be in use within an Institution and our core developers will provide you with the appropriate means and logic to utilize the customized elements.

Since custom fields are specific to an Institution’s specialized requirements, we are unable to offer them within the DMZ development environment though your code should be flexible enough to allow for the addition of these elements if they exist within an Institutional environment.

Example Vendor Readiness Test Scripts

Example Vendor Readiness Test Script: SOAP

Below is a sample VRT that might be administered for your application. Tests are tailored specifically to the Vendor/Provider relationship and as such we might not test all items listed below during every test, but all items should be taken into consideration as there will be no communication prior to the test as to what items will be involved.

Example Vendor Readiness Test Script: REST-Legacy

Below is a sample VRT that might be administered for your application. Tests are tailored specifically to the Vendor/Provider relationship and as such we might not test all items listed below during every test, but all items should be taken into consideration as there will be no communication prior to the test as to what items will be involved.