Data sources

Flow

• Overall flow
• Core fetch
• Postgres persistence
• Che
• API

Account Metadata

The goal of this project is to display more comprehensive account details so Banno users can find the information they need where they expect to find it without the need for a customer support interaction.

Drive Folder

The source of truth is the 06 - Full Account Properties List document.

Data Sources

The Account MetaData information comes from three different sources:

• jX
• PSCU
• SymX

Flow

Overall flow

core-fetch

In core-fetch we’ll fetch information about the accounts from jX, PSCU, and symX. We’ll see the process for the jX and PSCU.

PSCU

For PSCU we use an RPC client for jxchange-api in order to call the different CreditCardInquiry operations.

jX

For jX, we use the service in MDS (JxInquiryService) in order to fetch information from the AccountInquiry operation.

We’re getting the CoreProvider in AccountEnrichment using a Postgres call. Potentially, this should be replaced by calling to the banno-institution-aggregation shim service.

The CoreProvider is used in InquiryBindingFormatters for a couple of things:

1. Calculate the current and total amounts. See customer-issues/issues/4695
2. Calculate the right interest rate. See customer-issues/issues/4795

Since we’re getting information from different extended elements in jX, there is a utility for choosing the right extended elements based on the partnerAccountType. See JxExtensionElementMapper.scala for more information.

che

The che app will deserialize the account details (CheProtobufEnvelopeSerializer.scala) and store the information in the database (AccountDiscoveryPersistence.scala) using postgres-persistence.

postgres-persistence

The Account MetaData information is stored in different tables.

Some fields related with balances are stored in the account_balance table. These fields exist before the Account MetaData project but as part of this project, we’re adding information from new account types to these columns.

Other extra fields are stored in:

• jX: account_meta_data_jx
• PSCU: account_meta_data_pscu
• symX: account_meta_data_episys_loan

All the code related to the above tables is under the accounts package.

api

There are two endpoints that will show account metaData:

• GET /users/{userId}/accounts
• GET /users/{userId}/accounts/{accountId}

These two operations are handled in the following Plans:

• AccountsPlan
• SingleAccountPlan

The behavior is quite similar in both:

1. Call to the banno-institution-aggregation service for getting the CoreProvider in order to calculate the new account status field.
2. Call to the user-abilities service, to determine if the institution or the user has the metadata abilities enabled.
3. Fetch the account information and its metadata (if the abilities are enabled) from the DB.
4. Calculate the account status
5. Calculate the metadata.

Note on 1: We have worked in order to remove that call, but we can’t store a cross-institution value (CoreProvider) in an account. Another possibility is to calculate the account status in core fetch, there was a previous work but it was discarded.

Abilities

There are four abilities involved:

• accountJxMeta
• accountPSCUMeta
• accountPSCUMetaRewards
• accountSymXMeta

Account Status

This is a new field in the account property model of the API. The code resides in the JxMetaDataAccountMapper.scala file.

• Ref in consumer-api-docs

Account MetaData

The API provides a series of a generic objects to the clients with the idea that the clients don’t need to worry about what is the field they are showing.

This is how the model looks like in scala:

final case class MetaData(details: List[MetaDataGroup])

final case class MetaDataGroup(label: Option[String], values: List[MetaDataGroupEntry[_]])

sealed trait MetaDataGroupEntry[T] extends Product with Serializable {
  def label: String
  def `type`: MetaDataGroupTypeEnum.Value
  def value: T
  def extraDetails: Option[String]
}

object MetaDataGroupTypeEnum extends Enumeration {
  type MetaDataGroupTypeEnum = Value
  val Date, Count, Text, Money, Percentage = Value
}

• Ref in consumer-api-docs

The code resides in the JxMetaDataAccountMapper.scala file.

Currently, we’re showing 8 different MetaDataGroup lists:

• The default list: This list is quite similar to the information the clients were showing before the Account MetaData. If the user doesn’t have the abilities enabled and the account is not one of the mapped accounts (see next elements) we’ll show a default list.
• The PSCU list: This list will be shown if the account is a credit card account loaded from PSCU and the user has the accountPSCUMeta ability enabled. If the user also has the accountPSCUMetaRewards ability enabled, the list will contain information about rewards.
• The Loan / Line of Credit list: This list will be shown if the account is a Line of Credit or Debt loaded from jX and the user has the accountJxMeta ability enabled.
• The Deposit list: This list will be shown if the account is Deposit loaded from jX and the user has the accountJxMeta ability enabled.
• The Investment list: This list will be shown if the account is Investment loaded from jX and the user has the accountJxMeta ability enabled.
• The Epysis share list: This list will be shown if the account is a share account loaded from Epysis and the user has the accountSymXMeta ability enabled.
• The Epysis loan list: This list will be shown if the account is a loan account loaded from Epysis and the user has the accountSymXMeta ability enabled.

To see how the map is done, check the 06 - Full Account Properties List document.