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.

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.

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.

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

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

 
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>

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

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

 
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>

               
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>