The following diagram provides an overview of how Miracle Mobile Forms’ components communicate with each other.



Step 1 - Metadata Request

  • The Miracle Mobile App sends an application metadata request for a specific App Code to Miracle Mobile Forms’ Services over SSL (https://zon.miracletek.co/ws/MMPServices/[Version]/Service.svc/http)
  • Information about Mobile device requesting the metadata is also passed onto Services
  • Services receives the request for Application Metadata (Forms Definitions, Business Logic and Media Assets)
  • Services layer retrieves data from the database layer and sends Application Metadata and Form Definitions to Miracle Mobile app based on the App Code that was sent earlier

Step 2 - Customer Data Request 

  • The Miracle Mobile App requests Customer Data Entities from Services layer over SSL
  • Miracle Mobile Forms processes the entity requests, then passes on this request to Miracle Data Connectors
  • Miracle Data Connectors retrieve data from the customer’s database or back-end system through web services, and then returns transaction data to Services layer
  • Services passes on this transaction data to Miracle Mobile App in JSON format over SSL

Step 3 - Login Authentication 

  • Miracle Mobile App requests login authentication from Services using a username and password (encrypted)
  • Services then invokes the call to the appropriate Authentication connector (Active Directory, ADFS, Office 365 or Miracle Studio User Management)
    • In the case of ADFS, login is authenticated from an external Active Directory
    • In the case of the User Management Connector, login is authenticated using the User Management DB hosted in Miracle Mobile Platform AWS Cloud
  • The Authentication Connector validates login information, and returns the authentication token and user profile
  • Services passes on this data to the Miracle Mobile App in JSON format over SSL

Step 4 - Form Data Submission 

  • Miracle Mobile App submits forms’ transaction (business) data to Services in JSON format
  • Transaction data is also stored temporarily in Miracle Mobile Forms’ database on the cloud for transit and queuing purposes
  • Services processes the request and passes on the data to one or more Data Connectors (database or SOAP/REST)
  • The Data Connector sends the data to customers’ back-end systems over SSL depending on customer's configuration
  • Services returns a Success or Failure response to the Miracle Mobile app

Other Components

Following are some of the other components that are used extensively on the server and client side.


Server Side Components

  • Logs - All Service requests are logged and stored securely as flat files on AWS Cloud Watch, for auditing purpose. No customer transaction data is stored in our logs.
  • Amazon ElastiCache Redis – App metadata is temporarily stored in Redis Cache to avoid database access overhead. No customer transactional data is stored in Redis.
  • Miracle Studio Users Database – This database contains the users of Miracle Studio.
  • Platform Database – This is the master database which contains all the app metadata, form submissions and device logs.
  • Users and Roles Database - User information required for the User Management Connector is stored here.

Miracle Mobile App Components

  • Shared Gallery – The Shared Gallery on mobile device has all the stored image files taken from the camera or used from the gallery. This is a public accessible gallery.
  • SQLite DB – This database on mobile device stores app metadata, form drafts and submissions, connector entities data, and login credentials. Passwords are stored using AES-256 encryption. This database is private and inaccessible from outside the mobile application.
  • Data Files Local Form Cache - Form data is retained offline temporarily prior to submission to data stores or stored as drafts to be edited later. This data is stored in local flat files in the application’s private directory.
  • Metadata Storage – This contains app metadata cache which is fetched from the server once and then stored offline to generate forms.