MDX Real Time Workflow

Workflow

A user and member are created

When a user selects an MX product from your UI, your application determines whether the user and member already exist on the MX system. If they don’t, your server issues Create User and Create Member requests to MDX Real Time as needed.

You push new data to MX

Any time a user, member, account, or transaction is created, updated, or deleted on your system, the action is pushed to MX. These actions are ongoing, enabling all of the end user’s data to be on MX systems before they log into the service. Since only one action can be pushed through at a time, use a queue to process the actions as explained in Processing Actions in a Queue.

Creating objects in the MX system must be done according to the tree structure of objects in MX Data Architecture.

(Optional) Update large data sets with an API script

If you need to update large sets of data on MX’s servers in addition to building API calls and logic into your online banking platform, you can create a script that’s capable of looping through a table to perform simple API calls for each object with these steps:

Determine which endpoints need to be called.
Get a list of IDs required for each endpoint.
Create a loop to perform the API actions for each entity. Include a throttle to prevent exceeding the rate limit.

Reach out to your MX representative before you run the script so our teams are aware of any traffic increases and can monitor for potential issues that may appear.Here’s an example in Ruby of a loop to delete users:

require 'csv'

user_list = CSV.table("users_to_delete.csv").map { |row| row.to_hash }
user_list.each do |user|
  response = mdx_delete_user(
    :api_key => ":api_key",
    :client_id => ":client_id",
    :user_id => user[:user_id]
  )

  case response
  when ::Net::HTTPNoContent
    puts "[SUCCESS] [#{response.code}] [#{user[:user_id]} user deleted]"
  else
    puts "[FAILURE] [#{response.code}] [#{user[:user_id]} user not deleted]"
  end

  sleep 0.5
end

Processing Actions in a Queue

Depending on your integration, your system may have several actions that need to trigger a call to MDX Real Time to create, update, or delete objects in the MX system, such as when a user or account is created, an account balance changes, a pending transaction is created or posts, or if your system uses a nightly batch to push daily transactions.

Since only one action can be processed at a time with MDX Real Time, process actions in a queue to prevent errors. To do this, add action items to a database or cache, then pull them into a queue and use MDX Real Time to push that data to MX. Rate limits apply; refer to Rate Limiting for details.

Initial Queue

The initial queue is the first queue that attempts to push data to MX. It uses a listener or real-time read to determine when a new object is added to the database, at which point the first attempt is made to push the object to MX. If this attempt fails, a second attempt is made. If the second attempt fails, the action is added to the retry queue to avoid race conditions.

Retry Queue

If an action fails twice, it’s added to a retry queue. This queue determines how often failed actions are retried, and runs periodically by pulling items that need to be retried and attempting them once per pass.

Error Logging and Alerts

To help troubleshoot those actions that don’t make it through the initial or retry queue, log the errors and implement alerts. For example, you can set up an alert for when an action fails to succeed the initial attempt, or when an action has failed and the retry threshold has been reached.

Connectivity

Aggregation

Verification

Workflow

Processing Actions in a Queue

Initial Queue

Retry Queue

Error Logging and Alerts

​Workflow

​Processing Actions in a Queue

​Initial Queue

​Retry Queue

​Error Logging and Alerts

Workflow

Processing Actions in a Queue

Initial Queue

Retry Queue

Error Logging and Alerts