Learn the basic concepts

A BusApp is a little piece of code that can do stuff. See them as independant boxes that users can link to each other in order to create scenarios. As you can guess, there are 3 distinct types of BusApps:

1. Data producers usually bring data from your devices or services into Busit. (i.e.: CNN)
2. Data transformers usually modify or enhance data it receives and passes it on if necessary. (i.e.: translate)
3. Data consumers usually send data it receives to your devices or services. (i.e.: email)

An instance of a BusApp is a user's copy of that BusApp whereas the BusApp itself is more like a template. Instances are usually configured and linked in a flow so they are ready to be used. Users can have multiple instances of the same BusApp and of course, instances of different BusApps as well.

We speak about BusApps when it is not bound to a user, and about instances when it is.

A scenario is the path that a user creates when linking instances of different BusApps. A scenario usually starts with a producer in order to get data, then any number of transformers, then a consumer.

Scenarios are triggered either whenever some data is received in real time, or at specified intervals.

Every BusApp have one or more channels that can emit or receive data. See them as different doors that allows to enter or exit the BusApp.

1. Producers have output channels because you get data from them, data comes out of the BusApp.
2. Consumers have input channels because you send data to it, data gets inside the BusApp.
3. Transformers have both input and output channels because you put data in them and they return it after transformation, data gets in and then out of the BusApp.

Meanwhile, since BusApps can be multiple things at once (consumer and producer) they may have multiple input and ouput channels

An automatic (or cron) channel will be activated at regular interval. It is typically designed for producers that pull data from your devices or services. Moreover, it can have multiple applications for time related matters: birthdays, alarm clock, reminders,...

We talk about push and pull when it comes to exchange data accross devices or services. We always look at the origin of the data:

• When the device that has the data sends it directly to Busit, we say it pushes its data to the platform. On the other way around, when Busit has data and sends it directly to an external service, Busit will push data to that service.
  My phone pushes the data to Busit.
  Here is the data !
  

  

  

  
• When the device that has the data keeps it and waits for Busit to collect it every once in a while (see automatic channels) then we say that Busit pulls the data from that device.
  Busit pulls the data from my phone.
  Do you have some data ?
  

  

  

  
  Yes, here it is.
  

  

  

  

As you can guess, the ideal situation is always to push data because it is straight forward and allows realtime processing. However, this heavily depends on what the external devices or services support. On its side, Busit can collect data from external sources either in push or pull. However, Busit can only push data to external services. This is enforced by Busit's terms of use stating that we do not store data ; hence, we cannot keep it until some external service pulls it.

Some BusApps require configuration parameters to work properly. For instance, the Facebook BusApp needs your security token to be able to post or read messages.
There are 2 distinct ways to configure an instance:

1. If the configuration is basic, a simple form is automatically generated such that the user can set the value manually.
2. If the configuration is more complex, then the developer of the BusApp can use an external configuration website that will guide the user through the process.

Every BusApp configuration field may include values from the current message. Those values will be substituted at runtime.
In order to express binding, just put a message property name in double curly braces :

{{property}}

Example: if a message contains the following properties

• quantity: 3.141592
• price: 42

You can configure the Calculator BusApp to compute the cost as :

{{quantity}} * {{price}} / 100

Which will automatically be converted to :

3.141592 * 42 / 100