Quick start – Service element

Introduction

To refresh our memories, an element is the smallest unit of a flow. Elements are the building blocks we combine, to build our apps.

The Services element in Flow lets us connect our apps to other applications, service providers, or databases. We can also use services to extend the functionalities of a flow (say, to delay the flow, or schedule a task) and for end-user authentication. Currently, Boomi Flow service integrations are available for Salesforce, Box, Twilio, Gmail, and Microsoft Exchange, with more in the pipeline. We can also work with AtomSphere in Flow, which lets us use a variety of service connectors out-of-the-box.

Available service integrations

A Boomi Flow tenant comes with the ManyWho Identity service, which we can use to build public apps or apps that do not need third-party authentication. We will need to install the service in our subtenants. We can use the ManyWho Runtime service to create subflows and flow outs. The ManyWho Database service offers a hosted database for integration with Flow. We will use the ManyWho Email service to build apps that sends emails.

To access Services, log in to the Flow Drawing Tool, and click the Services tab.

Building service integrations

Wait! What is the air-speed velocity of an unladen swallow?

Before we start building service integrations, let’s ask ourselves if we absolutely need to. Boomi AtomSphere works seamlessly with Flow; which means we can use the entire library of AtomSphere connectors with Flow – without having to code or build a service from scratch.

If we do decide to, we can build our own service integrations using the Boom Flow API. We can build the integration in any language we like. Boomi Flow has a Service SDK for Java (recommended), C#, Ruby, and Apex.

Service integrations support the following capabilities:
  1. Database: The ability to connect to a remote data source and perform Save, Load, and Delete operations.
  2. Files: The ability to expose files stored in an external repository from within your Flow applications. This also allows users to upload and manage files through your flow.
  3. Social graph: The ability to embed a social network feed into your flow. This enables much richer collaboration within your apps, and helps increase adoption.
  4. Identity: For many customers, you will already have a directory of users in place. This allows you to re-use your existing identity system rather than creating yet another user repository.
  5. Location: The functionality for location is not yet released, but will soon allow you to tap into location services not provided by our platform. Location is increasingly a key tenant of any modern application.
  6. Logic: For many integrations, there are core API calls and pieces of logic that are better left in code. You can use the Service element to integrate with existing application logic – written in any language.
  7. User interface: Some applications may have user interface elements that would be useful to re-use within your applications. This service allows you to embed existing user interface rather than creating it from scratch on the Flow platform.
A few quick pointers:
  1. Service code: The Flow platform connects to external APIs via services. The role of the Service code is to act as a ‘proxy’ or gateway between the platform, and application, service provider, or database.  
  2. API-agnostic development with JSON/REST: The communication between the Service code and the Flow platform is done using JSON/REST. This ensures our builders can leverage multiple applications, service providers, or databases without having to learn the nuances of each API. For example, types, logic, or messages are the same, and automatically appear in the tooling with a service integration. Similarly, a Box Folder works the same way as an Account in Salesforce, or a SMS in Twilio. The Flow engine treats these as business objects, and apps are abstracted away from the underlying implementation.
  3. Reusable by design: You do not need to hard code configuration settings while building a service integration. Your services will be ‘multi-tenant’ and ‘multi-purpose’.
Boomi Flow Ninja // 
  1. When you are building your service integration, think of functionalities as distinct buckets like Database, Identity, Logic, Social, or Files. This will help you think about the features of the API, and where they best fit. Example: This is a CRUD object/API, I need to use the Database features in the SDK. This is a business logic that needs to be implemented in the service code, I need to use the Logic features.
  2. The Flow Service component gives you access to AtomSphere’s visual interface. Enter the required metadata, create a process to implement the service actions, and deploy the Flow Service component in a process. Refer to the AtomSphere process by providing the URL in a flow.

Check out the glossary for a definition of terms and key concepts that appear in the Boomi Flow website, Drawing Tool, technical documentation, blogs, and marketing communications.

If you need to take a closer look, click on the images to enlarge them. Have a question? Click the Help button on the bottom right-hand corner of this page to ask.