Methods & Scenarios for Integration with Mumba

There are many ways that Mumba can integrate with your Enterprise Business Information Systems (EBIS). When determining the best path for each system, we need to evaluate and select from the available options based on cost, ease of use and security policies.

Mumba’s integration capabilities are designed to offer a solution that meets each of these requirements thereby ensuring a smooth and effective implementation project.

In general, when integrating systems, as a customer you would provide us with:

  • Time with your technical team to map your data.

  • Time with your technical team to walk us through your infrastructure and/or system touch points.

  • Time with your network team for them to securely configure access between our Mumba servers on Amazon AWS and your EBIS.

What follows is a description of the 4 key integration options with their use cases and requirements.

#1 Integrating with a web API - Provided by your EBIS

We use this integration method when:

  • Your EBIS has enabled a web API (over HTTPS or websockets), either out-of-the-box or one that you can customise and extend yourself.

You provide:

  • Appropriate system account(s) with scheduled password rotation that our services can use to query the web API

  • An explanation of what API's you have available that allow us to interact with the required target endpoints

Examples:

  • SAP NetWeaver

  • D3

  • Kronos

  • Chris21 BRE

#2 Integrating with an on-premise Mumba API

We use this integration method when:

  1. We are dealing with an EBIS that does not expose a web API (and you do not have an internal team to build the services)

  2. Remote authentication using system accounts is not possible where realtime data is required

  3. We are dealing with complicated networking and security protocols and policies that are inhibiting a connection to your organization's infrastructure

You provide:

  • At least two Docker-capable servers, sized and specified to run the services that will connect to the Mumba WAMP Router over TLS/SSL

    • One server will be used for development/testing. As a guide, this should be no less than an AWS EC2 T2.Medium server, or equivalent (see https://aws.amazon.com/ec2/instance-types/\

    • One server will be used for production. As a guide, this should be no less than an AWS EC2 T2.Large server, or equivalent (exact server specifications will vary based on your individual requirements)

    • Additional servers may be required under some circumstances (for example, if a dedicated training instance is required)

We provide:

  • Mumba SDK Microservices that we have agreed to provide and maintain that connect the Mumba App to your EBIS

Examples:

  • A Mumba Web API to query your payroll system to get a list of payslips for the employee logged into the Mumba app

  • A Mumba Web API to work with a legacy EBIS that only supports a command-line query interface

  • A Mumba Web API for getting an employee's user profile by aggregating data from multiple internal information systems (as opposed to exposing all of those information systems individually to our servers)

#3 Integrating with a data warehouse/database

We use this integration method when:

  • Your company uses older or bespoke EBIS’s that were never designed to provide a web interface

  • The cost of developing a web enabled interface for the EBIS is prohibitive due to licensing or infrastructure costs

You provide:

  • Access through your firewall between the Mumba servers (on Amazon AWS) and your database instances over SSL

  • User accounts for the database servers with the appropriate permissions to access the required data

Examples:

  • A Data Warehouse has been used as an integration or reporting solution for disparate information systems.

  • A bespoke information system that uses a database backend.

#4 Integrating with a data interchange file

We use this integration method when:

  • there is no other reasonable means to connect to a web API or database directly, and

  • real-time data reads and writes are not necessary.

You provide:

  • The data files in an agreed, standard format (usually CSV, JSON or XML).

  • Secure access to a file system by which we can transfer files on a scheduled basis.

Example:

The Teradata (a big-data information system) support team is having trouble with user's not updating their passwords before they expire. Teradata does not provide any ability to email password reminders to the user accounts. Company policy does not allow Teradata to be accessed publicly (albeit securely) through the corporate firewall. In addition, installing vendor software on the corporate network requires an exhaustive vetting process.

In the meantime, the Teradata support team generates a CSV every day with usernames and password change data and sends that to a special location on their file network. Each night, Mumba copies this file via STFP and streams it to a service that will send an email to users when their password is about to expire.