jXchange Behaviors

Enterprise SOAP API > jXchange Environment > jXchange Behaviors

Canonicals

Canonicals normalize data that is common to all business service providers. It is a representation of data that is the same through all providers. Documentation can be found within the XSD contract files.

Nulls

JHA Null notifies the business service to ignore the specified element.

Nil Value	MOD	ADD
True	Remain	Set to Default

Element Value	Core Value Before	Core Value After
< element> </ element>	‘Y’	‘Y’
< element/>	‘Y’	‘Y’
JHANull = True	‘Y’	’ '

Version Tags

Version tags that are found throughout the contracts represent the point where new elements have been added for enhancements purposes. The labels, such as ver_1 or ver_2, do not represent a specific jXchange point release, but indicate the number of additions to that specific contract.

X_

To limit the size of the response payload and in an attempt to return relevant information to the request, jXchange incorporates the use of x_ elements for inquiries. These elements function as canonical values to specify the specific information needed by the consumer of the web service.

For example, when performing an account inquiry on a deposit account, not all information available is useful or needed for that specific request. The information needed can be limited to a much smaller set of values to work with. The x_ values are added to the request array element, IncXtendElemArray. The valid values are found in the corresponding response for that particular operation. If requested, the x_ value is found in the matching complex element in the response.

MTOM

MTOM, Message Transition Optimization Mechanism, is supported by jXchange. It supports sending attachments in a web service message. More information may be found here.

Institutional Routing

The ABA nine digit number assigned to financial institutions for the purpose of routing can be used as the routing number.

Institution Routing ID: Routing Number is required. The bank’s ABA number is used as the Routing Number.

Institution Environment: Required when using the Institution Routing ID.

The Institution Routing ID and Institution Environment must be used together and are both in the jX heading. There could be two environments with the same ID (ABA number), such as bank 123456789 PROD and 123456789 TEST. In the jXchangeHDR, you can specify both InstRtId and InstEnv, and they are used during authorization to validate that you have access to the specified institution and environment. If they are not specified, the jXchange servers default them to the institution and environment that the user name is attached to with default values. Only a single institution can be configured as the default for a given user name. jXchange 2012.0 and higher allows for a single user name to have access to multiple configured institutions by using the InstRtId and InstEnv elements to guide the routing of the message. This feature is not guaranteed to be available as it is a security choice for the banks to make. But you can ensure that your software can handle specifying InstRtId and InstEnv for future compatibility. These values are delivered with the credentials from the installation team for any particular bank.

Search Record Request and Response Behavior via Cursor Usage

To keep boundaries and payloads efficient, search services are designed to return large data sets in segments using the MaxRec and Cursor elements.

For example: Account 1234/D has 145 transaction records that could be returned using the Account History Search (AcctHistSrch) API. The consumer does not know how many records could be provided, but does know they can accept 50 records at a time. The chart below shows the flow of the MaxRec and Cursor element in use.

jXchange Cursor

Search Wildcards in jXchange

Search message request filter elements are decorated with an attribute that clearly conveys to the service provider the search expression. The search type attribute is enumerated with the values; Exact, StartsWith, EndsWith, Contains, and ContainsAll. These enumerated values could evolve based on industry standard operand expressions.

A service provider cannot require exact case matches. For example, if a consumer submits a last name data value of ~mcgrath~ then the service provider should respond back with any data values that match regardless of case which could include but not limited to ~McGrath~, ~Mcgrath~, ~mcgrath~, ~MCGRATH~ or any combination of case difference thereafter.

The search type value [ContainsAll] was placed into production in Release 2015.0.08. The [ContainsAll] should return the matched values that contain all of the values included in the search type attribute. This differs from the canonical value [Contains] which is much broader. The specific example is provided below.

Not all search message request filters qualify for wildcard searches. These include but not limited to enumerated elements, key elements, and range selection elements.

Example: Exact Match Search Response


Request:  <LastName SrchType="Exact">Smi</LastName>

Response: <LastName>Smi</LastName>
          <FirstName>John</FirstName>
          <LastName>Smi</LastName>
         <FirstName>Joe</FirstName>

Example: Contains Match Search Response

 
Request:  <LastName SrchType="Contains">Smi</LastName>

Response: <LastName>Smi</LastName>
          <FirstName>John</FirstName>
          <LastName>Smi</LastName>
          <FirstName>Joe</FirstName>
          <LastName>LockSmith</LastName>
          <FirstName>Jane</FirstName>

Example: Ends With Match Search Response


 Request:  <LastName SrchType="EndsWith">Smi</LastName>

 Response: <LastName>Dritiesmi</LastName>
           <FirstName>Lucas</FirstName>

Example: Starts With Match Search Response

 
Request:  <LastName SrchType="StartsWith">Smi</LastName>

Response: <LastName>Smith</LastName>
          <FirstName>Mike</FirstName>
          <LastName>Smitherrens</LastName>
          <FirstName>Jason</FirstName>
          <LastName>Smitty</LastName>
          <FirstName>James</FirstName>

Example: Contains All Match Search Response

               
Request:  <ComName SrchType="ContainsAll">Martha G jones</ComName>
               
Response: <ComName>Martha G Jones</ComName>
          <ComName>G Martha Jones</ComName>
          <ComName>Jones G Martha</ComName>
          <ComName>Martha Glayds Jonestien</ComName>

End of Day Core Processing and jXchange

Nightly processing, End of Day (EOD), Nightly Updates, Daily Updates, DayEnd are all synonymous terms describing a core banking task that completes a business day. This task is a core requirement that involves many functions that are too numerous to list here but a few items are to post transactions to account history, accrue interest, create reports, update account balances and many other responsibilities. The duration of nightly processing can vary greatly from institution to institution. During the processing window, it is important that data remains in a state that is consistent throughout processing. To ensure the integrity of the data, integration messages through jXchange are limited to Inquiry and Search functions only. These messages are identified by the suffixes of ‘Inq’ and ‘Srch’. Operations that end with ‘Add’, ‘Mod’ and ‘Validate’ are restricted during the processing window.

Below are the specific behaviors based on the 3 JHA banking cores that provide services to jXchange.

SilverLake and CIF 20/20 – Core Applications

Inquiry and Search operations are always available and are not restricted during End of Day (EOD) nightly processing. Except for Store Forward Messages (XferAdd, XferMod and XferSrch), the core programs called Business Services, are EOD aware, which means they know the last point during EOD processing where they can safely add or update records. The Store Forward Messages continue to behave as normal during Nightly Processing. The difference is SilverLake will hold the transaction and apply it to the next business day.

When calling an operation that is not available during nightly processing, a fault response will be returned with the error code of ‘34’ and a description of “Function is not available during Nightly Updates”. The operation will remain unavailable until processing has completed.

Here is an example message response for an operation that is not available during the processing window when one the following core applications are present.

End of Day Message Example for SilverLake and CIF 20/20


<FaultMsgRec>
 <ErrCode>34</ErrCode>
 <ErrCat>Error</ErrCat>
 <ErrDesc>Function is not available during Nightly Updates</ErrDesc>
 <ErrLoc>HBCASHUSR</ErrLoc>
</FaultMsgRec>

Core Director – Core Application

During the processing window, only Inquiry and Search based operations are available. Core Director’s JX interface won’t allow for any ‘Add’ or ‘Mod’ functions and if called, the error 1097 will be returned indicating Dayend is in progress. The operation will be available when DayEnd completes.

Additional products

SilverLake and CIF 20/20 share the same platform with additional JHA complimentary products. Among them are Netteller Host functions, Passport Host functions StreamLine and Argo Host functions. These products also provide additional business services to jXchange operations.

Summary

If an Inquiry or Search operation returns an error indicating it is not available during Nightly Processing or Dayend, a support call should be placed by the bank to the JH Call Center requesting the appropriate core provider group to assist. When SilverLake or CIF 20/20 is the core application, then the support case should be placed with the iAdapter Support provider group. When Core Director is present then with the CD/ACCESS provider group.

Have a Question?

Have a how-to question? Seeing a weird error? Get help on StackOverflow.

Register for the Digital Toolkit Meetup where we answer technical Q&A from the audience.

Last updated Thu Jul 14 2022