ICApp

In Rapidomize platform we name workflows as Intelligent Connected App, in short . Each workflow () consists of at least two Nodes.

Workflows are represented as graphs (as in DAG - Directed Acyclic Graph). In a workflow graph each vertex, referred to as a Node or Step, process your data in a stepwise manner to incrementally complete service/application logic. We name a workflow as an Intelligent Connected App, in short . Each workflow () consists of at least two Nodes.

First Node starts execution of your workflow service/application logic. Execution starts when an Event, such as timer ticks or new or updated data is available for processing occurs in the first Node. An Event can occur in a node due to a scheduled execution, api execution, retrieval of data from a service, … etc. This first Node where an event occurs, is called a Trigger and other Nodes in the workflow are called Actions. Actions can process/tranform your data or connect to remote services such as SaaS apps, integrate to your ERP systems, or databases to send, receive or store data. In an you can have More than One Action. However, for the time being, can have Only One Trigger Node.

How ICApps are represented?

are represented as graphs. Following are few examples:

1. having one Trigger and one Action. Here, every time an Event occurs in Trigger, the Action gets executed. So the data from the Trigger is fed into the Action for consumption.

   

2. having one Trigger and two Actions. Here, every time an Event occurs in Trigger, both the Actions get executed concurrently. So the Event’s data from the Trigger is fed simultaneously into both Actions for consumption.

   

3. having one Trigger and two Actions in sequence. Here, every time an Event occurs in Trigger, both the Actions get executed one after the other as per their order. The Action1 gets executed first followed by Action2. The Event’s data from the Trigger is fed first into the Action1 and then to Action2. This model allows Action2 to consume both the data from original Event and the data received from Action1.

   

How ICApps are executed

ICApp’s data formats

• We utilize JSON format as the normalized form to represent data for ICApp execution. If the apps, services or devices you connect, produce non-JSON data, then the normalization process encodes such data into JSON form, so that they can be processed consistently.
• Event/data received or status produced by Actions are available as Macros at desiging time of the . This allows you to feed such event/data/status from one Action to another by configuration.

executes each time Trigger is executed. Executions depend on the type of Trigger in your

Types of Triggers

There are three types of triggers.

• Scheduler based Triggers (Cron/Timer): Allows you to configure a periodic (crons style) execution schedule for your .

  

• APIs or Webhooks based Triggers - These Triggers are executed instantly when an API or Webhook is invoked. For example using HTTP POST, or MQTT message is published.

  

  

• SaaS App Triggers - There are two categories

  • Instant - These Triggers are executed instantly when SaaS App sends us an Event. For example when a new record is created in the SaaS App.
  • Scheduled - Rapidomize periodically polls and check for Event data for your SaaS App. Minimum polling interval that you can select for your ICApp depends on your account plan.

  

Minimum polling interval per Account Plan

• Free or Lite plans - 15 min
• Standard plans - 5 min
• All other plans - 3 min

Authentication & Authorization for APIs or Webhooks based Triggers

Authentication

Token based API authentication are supported for the time being. Token is used in the Authorization header for App/Device backends where HTTP headers can be specified. Otherwise token can be used with URL query parameters. However, latter method is not encouraged unless your app is frontend only i.e. static webapp.

All request must be submitted using HTTPS to avoid compromising your token.

Authorization

If your App/Device has a separate backend, it is highly recommended to whitelist your Domain or IP address of your servers.

Auth header

When using HTTP REST API without the SDK, for HTTP Basic authentication you need to use username and password separated by a single colon (":") character within a base64 encoded string in the credentials. Here you must leave the username blank and specify the token as password field of the HTTP Basic Auth header.

In plain HTTP, that is

Authorization: Basic  Base64 encoded :YOUR_TOKEN