Error Handling
Error Handling: Provider, Integration Layer, and Communications
While developing within the JH environments, the solution should be able to capture and manage errors presented. Consumers should have basic familiarity with errors presented by JH providers, integration layer environment and generic XML errors. Errors listed should be taken into consideration as to not cause the end users unnecessary downtime. Below are some examples of each type.
SOAP Examples
<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/oasis-200401-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>
REST-Legacy (JSON Examples)
{
"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
}
]
}
FAQ
Q: (SOAP) I have been provided with jXchange credentials. I am receiving an “Access is denied” error message in response to my request.
A: There can be several factors that cause this error. Please verify the following in your attempt to correct:
- jXchange URL - some environments use the same domain name, but your account is configured on a specific jXchange environment and will not work on any other jXchange environments.
- InstRtId - your account is authorized to a specific routing ID, which will coincide with the financial institutions Fed routing and transit number MOST of the time for production jXchange configurations.
- InstEnv - your account is authorized to a specific environment variable and you will have separate credentials for production and test institutions (where applicable).
- ValidConsmName - each product’s service account is configured with a “Validated Consumer Name” claim and what you provide in the XML request must match the value that has been configured. (Case Sensitive)
- ValidConsmProd - each product’s service account is configured with a “Validated Consumer Product” claim and what you provide in the XML request must match the value that has been configured. (Case Sensitive)
All of these values are provided to you each time you receive jXchange credentials. If you have confirmed the correct values are being passed based off of the values you were provided with your jXchange credentials, a Jack Henry support case will need to be logged to further assist. For live financial institution environments, someone from the financial institution must open a case via the For Clients portal with the jXchange Support group. For the Jack Henry DMZ sandbox, the vendor must open a case via their Vendor portal.