Getting Started

Updated on July 14, 2022

Introduction

This information is to help jump start your development as a new consumer of jXchange Service Gateway (jXchange). Please review all the information below, as well as the related documentation listed under the “Minimal document reading requirements” and “Optional reading if relevant to project” sections before starting a new development effort.abcdef

The Use Case responses provided below are a good starting place for your development, but please note that additional discussion and rewrites are possible as we work through the onboarding process.

This information is not intended to be a comprehensive list for all operations and behaviors as there are other documents that fulfill that requirement.

As a new consumer of Enterprise Integration & Services (EI&S) services, your company will be responsible for the complete development life cycle of your new product. JHA does not provide code reviews, nor do we require code supervision for your product.

Jack Henry application programming interfaces (API) are developed as contract-first, meaning the structure is designed prior to the supporting service. The are several reasons for this, one being the contracts are designed with the enterprise perspective, ensuring all potential providers of the services are represented. Any references made regarding contracts for the SOAP APIs, refer to the XSDs and

IMPORTANT: WSDLs that can be found in the Developer Downloads and Resource Center. The file name contains the contract version, using this name format - TPG_RYYYY.X.XX_XSD.

Minimal document reading requirements

The following documents located under Developer Downloads and Resource Center are required reading before any work begins on any new jXchange consumer integration. These guides contain crucial information needed before development with jXchange.

Optional reading if relevant to project

These documents are optional but are still highly recommended reading for new integrations with the related providers.

Other documentation

The EIP Downloads section also contains numerous important documents regarding other Jack Henry products, such as EES, ODI, and Xperience, so please review those as well if you plan on using IDG products beyond jXchange.

DMZ Environment Access

URL:

https://JXTest.Jackhenry.com/jxchange/2008/ServiceGateway/ServiceGateway.svc

 

 

Username:

{Username}

Password

{Password}

 

 

 

InstRtID

InstEnv

Silverlake

011001276

TEST

CIF 20/20

2020

TEST

Core Director

11111900

TEST

 

 

ValidConsmName

{Vendor Name}

ValidConsmProd

{Product}

The information above can be used to send operations to our externally accessible jXchange instance. This is a sandbox environment that is commonly referred to as the DMZ. This instance is used by third parties to develop their jXchange integration.

The InstRtID and InstEnv values above denote three different jXchange configurations, each tied to a different JHA core provider. The DMZ jXchange currently tied to Silverlake uses 011001276 and TEST, the CIF2020 gateway uses 2020 and TEST, and Core Director uses 11111900 and TEST.

Your provisioned access to these gateways may vary depending on which core(s) your company identified for use in the initial onboarding documentation.

For all jXchange integrations, the combination of InstRtId and InstEnv values will be unique to each jXchange instance.

Important items to note: A single username and password may be used during initial development against the DMZ jXchange environment. However, for production installs, JHA will provide a unique set of credentials for each institution environment. The jXchange URL, InstRtId, and InstEnv could also vary per production fininacial institution (FI) environment as well. The ValidConsmName and ValidConsmProd values will always be the same per consuming product. Also please note that all development work should be done against our DMZ environment listed above, and never against a FI’s production environment.

jXchange Header

The jXchangeHdr structure is required for all jXchange operations. Although most header elements are listed as optional according to the contracts (XSDs), it is highly recommended that they are always populated properly according to their use and the purpose of the consuming product. Certain behaviors and functionality may be adversely impacted if improper values are provided.

For a more detailed description of the jXchangeHdr and its elements, please refer to the document titled jXchangeHdr_Consumers.pdf, which is available via the EIP downloads page.

Important Note: The following values in the <jXchangHdr> must be configurable per instance and *not* represented in a code base (not hard-coded) since these required values can and will change between environments: AuditUsrId, AuditWsId, ConsumerName, ConsumerProd, InstRtId, InstEnv, ValidConsmName,ValidConsmProd..

Example jXchange Header

   <jXchangeHdr>
     <JxVer/>
     <AuditUsrId>AuditUsrId</AuditUsrId>
     <AuditWsId>AuditWsId</AuditWsId>
     <AuthenUsrId/>
     <ConsumerName/>
     <ConsumerProd/>
     <Ver_1/>
     <jXLogTrackingId>{GUID}</jXLogTrackingId>
     <Ver_2/>
     <InstRtId>011001276</InstRtId>
     <InstEnv>TEST</InstEnv>
     <Ver_3/>
     <BusCorrelId/>
     <Ver_4/>
     <WorkflowCorrelId/>
     <Ver_5/>
     <ValidConsmName>{ValidConsmName}</ValidConsmName>
     <ValidConsmProd>{ValidConsmProd}</ValidConsmProd>
     <Ver_6/>
   </jXchangeHdr>
    
  1. <JxVer>- the value in this element is informational only and will not be utilized by jXchange, but the response will contain the current version of jXchange.
  2. <AuditUsrId> and <AudiWsId> - These are not required and can be used to track the username and workstation of the person/agent making the request.
  3. <ConsumerName> and <ConsumerProd> - These are independent of <ValidConsmName> and <ValidConsmProd> and should not be populated unless directed by JHA.
  4. <jXLogTrackingId> should be a new unique value, preferably a GUID for every operation call. Having a unique value in jXLogTrackingId is extremely valuable for researching issues in a bank’s environment.
  5. <BusCorrelId> is used to group multiple units of work. This might include several calls used to add a new customer with an associated new account.
  6. <WorkflowCorrelId> is reserved for JHA workflow application services. Please refer to the jXchangeHdr_Consumers.pdf for more information.
  7. <ValidConsmName> and <ValidConsmProd> elements are required that are provided to you by JHA and will be used for all integrations in development and production locations.
  8. <Ver\_\*> - These tags are required throughout the jXchangeHdr and the XML. Their placement is exact as they are used to mark a code change that has occurred in the XML and allows for backwards compatibility.

CustSrch Sample XML for SilverLake Core

HTTP Header

Request

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <SOAP-ENV:Header>
  <wsse:Security
   xmlns:wsse=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:wsu=
    "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <wsu:Timestamp>
    <wsu:Created>2022-01-25T14:40:49Z</wsu:Created>
    <wsu:Expires>2022-01-25T14:45:49Z</wsu:Expires>
   </wsu:Timestamp>
   <wsse:UsernameToken
     xmlns:wsse=
     "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <wsse:Username>{Username}</wsse:Username>
    <wsse:Password
     Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-
     1.0#PasswordText">{Password}</wsse:Password>
    <wsu:Created
   xmlns:wsu="http://docs.oasis-open.org/wss/2004oasis-200401-wss-wssecurity-utility-1.0.xsd">
   2022-01-25T14:40:49Z</wsu:Created>
   </wsse:UsernameToken>
  </wsse:Security>
 </SOAP-ENV:Header>
 <SOAP-ENV:Body>
  <CustSrch
      xmlns="http://jackhenry.com/jxchange/TPG/2008">
   <SrchMsgRqHdr>
    <jXchangeHdr>
     <JxVer/>
     <AuditUsrId>AuditUsrId</AuditUsrId>
     <AuditWsId>AuditWsId</AuditWsId>
     <AuthenUsrId/>
     <ConsumerName/>
     <ConsumerProd/>
     <Ver_1/>
     <jXLogTrackingId>{GUID}</jXLogTrackingId>
     <Ver_2/>
     <InstRtId>011001276</InstRtId>
     <InstEnv>TEST</InstEnv>
     <Ver_3/>
     <BusCorrelId/>
     <Ver_4/>
     <WorkflowCorrelId/>
     <Ver_5/>
     <ValidConsmName>{ValidConsumerName} </ValidConsmName>
     <ValidConsmProd>{ValidConsumerProduct}</ValidConsmProd>
     <Ver_6/>
    </jXchangeHdr>
    <MaxRec>3999</MaxRec>
    <Cursor/>
    <Ver_1/>
    <Ver_2/>
    <Ver_3/>
   </SrchMsgRqHdr>
   <PersonName>
    <ComName/>
    <FirstName/>
    <MiddleName/>
    <LastName>smith</LastName>
    <Ver_1/>
   </PersonName>
   <Ver_1/>
   <Ver_2/>
   <Ver_3/>
   <Ver_4/>
   <Ver_5/>
   <Ver_6/>
  </CustSrch>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Sample Process Flow Diagram for jXchange Integrations

Interagtion flow diagram

This is an example flowchart of how a workflow might look and can be modified to meet certain product requirements. Note that the customer record is the root and must exist prior to associating accounts.

Commonly Used Operations

Below is a list of some commonly used operations when integrating with jXchange. The full list of APIs can be, and additional use cases found on the jXchange Service Gateway section of the EIP.

I want to… Operation Name XSD/WSDL Container
Inquire on existing customer information CustInq Customer
Search for an existing customer(s) CustSrch Customer
Create a new customer record CustAdd Customer
Modify an existing customer record CustMod Customer
Attach identity information to a customer record IdVerifyAdd Customer
Add an informational message to an account or customer record CustMsgAdd Customer
Add additional addresses to an account or customer AddrAdd Customer
Search for existing additional addresses AddrSrch Customer
Modify existing additional addresses AddrMod Customer
Create a relationship between customers CustRelAdd Customer
Modify a relationship between customers CustRelMod Customer
Request an account number to be used for a new Loan account AcctIdGen Customer
Retrieve new account input defaults SvcDft Customer
Retrieve provider parameter information SvcDictSrch Customer
Create a new account record AcctAdd Deposit
Modify an existing account record AcctMod Deposit
Inquire on an existing account AcctInq Inquiry
Search for an existing account AcctSrch Inquiry
Search historical transactions AcctHistSrch Inquiry
Verify transfer rights between accounts XferSrcDestSrch Inquiry
Search for existing transfer(s) XferSrch Inquiry
Inquire on an existing Line of Credit LOCAcctInq Inquiry
Search for an existing FASB91 record FASB91Srch Inquiry
Inquire on an existing loan escrow record EscrwInq Inquiry
Search for existing loan registration records LnAppRgtrSrch Inquiry
Perform an OFAC search on a name OFACSrch Inquiry
Search for existing relationships beween accounts AcctRelSrch Inquiry
Add a new Line of Credit record LOCAdd Loan
Validate a new Line of Credit prior to creation LOCAddValidate Loan
Modify an existing Line of Credit LOCMod Loan
Add a new FASB91 record FASB91Add Loan
Validate a new FASB91 record prior to creation FASB91AddValidate Loan
Modify an existing FASB91 record FASB91Mod Loan
Add a new loan escrow record EscrwAdd Loan
Validate a new escrow record prior to creation EscrwAddValidate Loan
Modify an existing escrow record EscrwMod Loan
Add a new loan registration record LnAppRgtrAdd Loan
Validate a new loan registration record prior to creaction LnAppRgtrAddValidate Loan
Modify an existing loan registration record LnAppRgtrMod Loan
Transfer funds between two existing accounts XferAdd Transaction
Validate a transfer prior to moving funds XferAddValidate Transaction
Modify an existing transfer XferMod Transaction

Location of additional Use Cases and Tutorials

Click here Tutorials Page to see additional use cases.