Development using SOAP

jXchange Self Registration

JH is happy to announce that we now offer self registration to use our jXchange DMZ Development Environment. We have designed a tutorial on how to apply.

Take Me There  

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.

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. Jack Henry(JH) does not provide code reviews, nor do we require code supervision for your product.

jXchange Service Gateway is our native SOAP interface and payloads are formatted in XML. We do offer REST over SOAP using a translation layer in Mulesoft. If REST is the preferred method, the documentation for the SOAP APIs will still be pertinent to complete your development since the JSON message structure formatting will follow the XML message structure.

Jack Henry application programming interfaces (API) are developed as contract-first, meaning the structure is designed prior to the supporting service. The primary reason being the contracts are designed with the enterprise perspective, ensuring all potential providers of the services are represented.

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

DMZ environment access

Cores

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 JH core provider. The DMZ jXchange currently tied to SilverLake uses 011001276 and TEST or Ovation, 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.

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 expected 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 jXchangeHdr Information page.

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. (This field may be blank.)
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. (This field may be blank.)
3. <ConsumerName> and <ConsumerProd> - These are independent of <ValidConsmName> and <ValidConsmProd> and should not be populated unless directed by JH. (These fields should be blank unless directed by JH resource.)
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. (This should not be blank.)
5. <InstRtId> and <InstEnv> are the bank’s ABA/routing number and the bank’s core environment (UAT, TEST, etc.). (Required.)
6. <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.(This field may be blank.)
7. <WorkflowCorrelId> is reserved for JH workflow application services. Please refer to the jXchangeHdr Information page for more information. (This field may be blank.)
8. <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. (Required.)
9. <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. (Required as part of the call, though the fields will be self closed as shown in above sample.)

CustSrch sample XML for SilverLake core

HTTP header

• POST /jxchange/2008/ServiceGateway/ServiceGateway.svc HTTP/1.1
• Host: jxdmz.jackhenry.com
• Content-Type: text/xml; charset=UTF-8
• Content-Length: 2607
• SOAPAction: http://jackhenry.com/ws/CustSrch

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">
            <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>
            </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>

Multi-Provider Testing

If a solution will be touching multiple JH providers (ex: Silverlake, CIF 20/20, Core Director, etc.) it is important to understand that although most of the operations are not provider specific and are interchangeable from the consumer standpoint. However, the jXchange environment and its APIs do not provide normalization and behaviors/responses can differentiate a great deal based on the provider that is being accessed. It is the responsibility of the consumer to test their service calls across every provider environment to ensure their product can handle any potential different behavior/responses between individual providers.

A simple example of this can be found in the account types between SilverLake and Core Director. A deposit account for SilverLake uses the identifier of D while Core Director uses the identifier of 10.

DMZ Demonstration Use Statement

Jack Henry’s Integration Sandbox (aka DMZ) is a developer focused environment where all consumers are integrating with shared systems of record, whether banking cores, SilverLake, CIF 2020, Core Director and Episys, or complimentary products such as Synergy and Synapsys. The nature of this environment does not necessarily lend itself to Third Party Vendor product demonstrations utilizing Jack Henry’s Enterprise Integration solutions. Third Party Vendors may use these systems for demonstrations, with the following understanding.

• Data can and may change based on usage and access by other consumers during your demonstration window.
• Access will not be limited to prevent other consumers from using the environment during a window of time.
• Jack Henry personnel will not be available for immediate troubleshooting if issues arise during a demonstration.
• System maintenance is scheduled Monday between 4:00 pm and 6:00 pm US Central time.
• The SilverLake banking core runs its nightly processing Monday through Friday, beginning at 8:00 pm Central and normally completing before 9:00 pm US Central time.
• After hours support is not available for the DMZ. Business hours are 8:00 am to 5:00 pm US Central time.

Sample process flow diagram for jXchange integrations

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 APIs, Tutorials and Sample Data

See Commonly Used APIs for a quick list of apis that are most used when consuming jXchange APIs. We also offer a Tutorials section for additional use cases. A full list of APIs may be found within the API by Provider or API by Reference.

Sample data is provided to assist with starting your development journey. Within the SOAP Documentation page, locate the file named DMZTestAccounts_SL_2020_CoreDirector_Episys.

JH Public Postman Collection

For those consumers that wish to test our APIs via Postman without first using development efforts, we offer a public Postman collection of our SOAP APIs. Please reference our JH Postman Public Collection tutorial for more information.