DXC Hogan Customers System API

About Hogan Customers System API

Hogan APIs are the system-level APIs used to interact with Hogan business applications like CIS (Customer Information System), IDS (Integrated Deposits System), FSS (Financial Support System), ILP (Integrated Loans Processing), and CAMS II (Cards and Merchant System). This system of record APIs exposes Hogan's business functions to client applications via IBM z/OS Connect EE which provides JSON message format based RESTful API access to z/OS applications like Hogan.

z/OS Connect EE server components are installed on the mainframe and expose mainframe functions as web-based RESTful APIs which can be accessed over the web using the HTTP protocol. Because of the distinctive behavior of Hogan, z/OS Connect EE cannot work out of the box with it. DXC Technology built a Hogan interface by extending the Hogan Umbrella engine to provide an infrastructure for simplification of the API build process inside the Hogan environment as well as a conduit for passage of data inside and outside the Hogan environment. Client applications are expected to send and receive data in JSON-based message format which is converted to Hogan understandable data format by a combination of components running inside z/OS Connect EE as well as inside Hogan core. DXC provides 81 CIS, IDS, and FSS APIs bundled as separate families along with the infrastructure components. However, the interface infrastructure is meant to build APIs in the bank’s customized environment.

Following general business functions are supported by Hogan APIs:

-Customer creation and maintenance

-Account (deposits, loans, Cards) creation and maintenance

-Address creation and maintenance

-Relationship management – Customer to account, customer to address, etc.

-Transaction Posting

-Transaction listing, Statements

-Funds Transfer

-Create manage Direct Debit

-Account Sweep

-Restraints and hard holds

-Account Payoff

-Branch and currency management

Prerequisites

To use these APIs, you should be familiar with:

• Web-based RESTful APIs which provide standardized JSON input & output payloads based on OpenAPI specification format
• Mule runtime engine
• Anypoint PlatformTM Connectors and Anypoint PlatformTM Studio
• Mule runtime engine concepts
• Elements in a Mule flow and Global Elements

API configuration

Hogan APIs are deployed on the z/OS Connect EE server on the mainframe platform. These are invoked via the web-based URI along with the appropriate HTTP verb. Invocation of API can be done by providing the following header parameters:

Expected Flow

The Hogan APIs allow client applications to invoke Hogan business functions using web-based HTTP invocation including header parameters, authorization parameters, HTTP verb, URI path & query parameters, and JSON request payload. The flow of API invocation passes through the z/OS Connect EE and executes the respective runtime components based on the URI path. These components in turn pass the control into the Hogan API Umbrella interface components defined for an API. These APIs invoke Hogan business application components to Inquire/Add/Modify/Delete objects inside the Hogan application and the outcome of the execution is sent back to the client application via the z/OS Connect EE server.

Hogan APIs response provides HTTP 400, 500, 405, and 503 as fault codes. HTTP 200 signifies a successful execution of an API. Further status of an API execution in the case of HTTP 200 is shown as part of every API JSON response structure. An example of a standard status message is shown below.

"xStatus": {

"applicationCd": 0,

"statusCd": 64120,

"statusMessage": "ACCOUNT ADDED TO FILE",

"severity": "E"

}

Use cases

Hogan Customer APIs are the system-level APIs used to invoke the following Hogan CIS (Customer Information System) business functions.

1. Create Customer

HTTP Verb: POST

Purpose: Create an individual or commercial customer and attach an address to the newly added customer. Email addresses can also be added and attached to new customers.

Request Payload: All CUS1, CUS2 & CUAD fields.

Response Payload: All CUS1, CUS2 & CUAD fields. The response brings out the multiple occurrences of Bank relationships, bank services, remarks Customer Remarks, and Customer Identification objects. Linked address or email address is also part of the response.

2. Relate Customer to Account

HTTP Verb: PATCH

Purpose: Link or delink an existing account to an existing individual to business customers. Also, provides the capability to modify attributes like relationships, owner percentage, analysis, and pricing flags. 16 occurrences of accounts are supported.

Request Payload: All CUAC fields.

Response Payload: All CUAC fields. 16 occurrences are supported.

3. Get Customer Profile

HTTP Verb: GET

Purpose: Provides Customer demographic data, related account information (optional), related closed account information (optional), remarks, bank relationships, bank services, reference information, alias information, social relationships, credit scoring information, last contact information

Request Payload: Basic CUPR fields like COID, Name, Tie, Historical account indicator, and Closed account indicator. It also supports search based on tax ID instead of Customer name or Customer number.

Response Payload: Response brings a lot of fields related to customer demographics, related address, 25 occurrences of customer remarks, 100 occurrences of related accounts, 20 occurrences of bank relationships, 20 occurrences of bank services, 5 occurrences each of reference information, alias information, and social relationships. Credit scoring and last contact information.

4. Get Customer List

HTTP Verb: GET

Purpose: Customer list filtered on customer full or partial name. The search can be further refined using taxpayer number, birth date, Postal Code, and Street number.

Request Payload: Key fields as required for CULO screen and other pagination control fields.

Response Payload: Customer and their address details. Maximum 80 occurrences can be extracted in the execution of an API. Further extraction of customer records will require another hit into the mainframe with appropriate offset and limit value in the request payload. Note: Occurrences can be increased based on the bank’s requirements.

5. Get Customer Relationships

HTTP Verb: GET

Purpose: Fetch customers and accounts related to an address.

Request Payload: Key fields for primary customer and pagination control fields.

Response Payload: Primary customer information. Pagination control fields (offset and limit for each type of relationship). Related customers (maximum occurrence 20) and related account details (maximum occurrence 20).

6. Update Address Account

HTTP Verb: PATCH

Purpose: Maintain an address for an account. Supports DELNA and CHG action on the ACMN screen. This screen is also used to bring in Checking or a Term Deposit account from IDS into CIS application databases using the ‘ADD’ action.

Request Payload: All fields on the ACMN screen.

Response Payload: All updated fields on the ACMN screen.

7. Update Customer

HTTP Verb: PATCH

Purpose: Maintain customer information. This API is used to maintain information on CUM1, CUM2, CUAI, CUCD, CURE, CUBK. Action A=ADD, C=CHANGE, D=DEL supported for CUCD (commercial contact information), CURE (related customer and related accounts), and CUBK (related bank services and related bank relationships) screens.

Request Payload: All CUM1, CUM2, CUAI, CUCD, CURE, and CUBK fields.

Response Payload: All CUM1 & CUM2 fields, CUAI (Personal data, Privacy data, Document data, and FATCA data), CUCD (Commercial contact data), CURE (Related customers and related accounts), and CUBK (Customer bank relationships and bank services).

Additional resources

• Swagger specification documents of each of the Customer API

About DXC Technology