Getting Started with Widgets

Widgets must be enabled in your AtomSphere account. Contact your Boomi sales rep for more information.

Note: Before creating Widgets, you should be familiar with general Process development, Process deployment, Process Properties, and Process Extensions.

In this article:

Overview

The AtomSphere Widget framework allows AtomSphere developers to create pre-packaged integration solutions that can be installed and managed by end users via a simple install wizard. Widgets can be embedded within another web application and white labeled for a seamless end user experience. A Widget end user's experience is completely contained within the Widget Manager; they do not have access to the underlying AtomSphere platform. From the Widget Manager, the user can install, manage, and monitor the Widgets' integrations in a self-service manner.

Widgets are built using the AtomSphere platform and represent a different way of deploying and managing Processes for end users. Essentially, Widgets are a user-friendly install wizard that sits on top of a normal integration Process and is used to configure specific aspects of that Process, such as Connection credentials and even field level mapping. If Processes and Connectors abstract the details for connecting to various applications and manipulating data, Widgets take it one step further and abstract the Processes themselves. This is accomplished by defining Process Extensions for the various configurations that will vary from customer to customer such as Connection settings, Process Properties, schedules, and even field-level mapping.

Who Builds Widgets?

Widgets are intended for partners and third party developers who want to offer a packaged integration solution to their constituents.

Common examples include:

• SaaS Application Providers who want to offer pre-integrated solutions with their common integration touch points.
• Systems Integrators who want to "productize" their integration knowledge and streamline customer implementations.

Widgets are embedded within a "hosting" application to offer a seamless end user experience.

Important Concepts

• Simple Wizard-driven interface - The Widget wizard greatly simplifies the steps required to provision the integration for the customer, reducing implementation time and even enabling self-service.
• Single instance of Process configuration - A Widget sits on top of a single instance of a Process configuration that is deployed multiple times, once for each customer. It is critical to understand Widgets are not "templates" that are copied for each customer.
  • This means Widget developers only have to maintain Process configuration in one place.
  • This also means developers can push Widget and Process configuration updates automatically to the entire install base by simply deploying a new version of the Process configuration. No patches or updates to need to be downloaded or applied manually.
  • Mass customization - Each customer will configure the Widget with its own credentials, preferences, and even custom field mapping.
• Cloud or Local Deployment - Depending on the applications and data sources used in the integration, a Widget may be deployed to the AtomSphere Cloud or locally with an Atom installed within a customer's network to access data behind the firewall.
• Time-based Trials - When an end user installs a Widget instance, it is provisioned as a time-based trial account. The user can then test drive and evaluate the Widget before deciding to purchase. The Widget developer can define the trial length. More about Trials.
• Customers will not have AtomSphere edition accounts - Widget end users do not need an AtomSphere edition account. Partners should not provision AtomSphere edition accounts for Widget prospects. The Widget Manager handles the account creation for each customer's Widget instance automatically.

How It Works

The basic steps for building and provisioning a Widget are as followed. Read the Building Your First Widget Tutorial for more detailed, step by step instructions.

1. The Widget developer creates the Process(es).
2. The Widget developer specifies Process Extensions to allow certain settings like Connection credentials to be configured later by the end user.
3. The Widget developer designs a Widget wizard, the configuration wizard the end will go through when setting up the integration. This is where the end user will provide values for the various Process Extensions.
4. The Widget developer deploys the Widget process to create a deployment version.
5. The Widget developer creates a Widget Manager and assigns the new Widget and deployment version to that Manager.
6. The Widget developer embeds the Widget Manager within a partner application.
7. The end user logs into that partner application and accesses the Widget Manager interface.
8. The end user goes through the Widget wizard steps to configure and provision a new Widget instance.
9. The new Widget instance (including a local Atom if necessary) is provisioned automatically and ready to execute Processes.

Considerations

Widgets are Predefined Integrations

When designing the Processes for a Widget, remember that you are building a "one-size-fits-all" integration. Research your industry's best business practices and solicit feedback and requirements from customers and end users to understand the common touch points and business rules. The underlying Process logic is static and cannot be changed for each customer's implementation. The objects, general work flow, record selection criteria, processing logic and validations cannot be customized "on the fly".

However as mentioned above, certain configuration settings that will vary from customer to customer such as Connection settings, Process Properties, schedules, and even field-level mapping, can be exposed for the end user to configure. Through the use of Process Property Extensions, you can create "preferences" that allow users to determine how the Process should execute. Although the underlying configuration is static, you can build logic into the Process to conditionally execute certain paths based on the value of that Process Property.

For example, for an integration that syncs Opportunities from a CRM application to a back office accounting system, you could expose a Process Property that lets the Widget user choose if those Opportunities should create a Sales Order or an Invoice. The static Process configuration would contain a Decision that evaluates the Process Property value ("sales order" or "invoice") and executes the appropriate logic.

See a step by step example of how to use Process Property "preferences" in Building Your First Widget - Part 2.

Not Every Integration is "Widget-able"

It is important to note that not all integration scenarios are able to effectively be packaged and distributed as Widgets. Because the underlying Process configuration and work flow are static, integration scenarios that require customized logic, selection criteria, or processing rules per customer are not good candidates for Widgets. For example, integration scenarios wherein each customer will have their own custom objects/record types are not good candidates for Widgets because the Process components (Operation, Profile, Map, etc.) could not be reused across implementations. However that is not to say Widgets cannot be built with custom objects. It is certainly possible to develop a Widget Process that references a custom object under the assumption that custom object will always be present--maybe as part of a broader customization module/package/bundle for a given application.

Currently, Widgets cannot contain real-time Processes, that is, Processes that are configured to receive/listen for data in real time. This means you cannot include Processes that use the Web Services Server or AS2 Server capabilities.

Widgets are best suited for integrations with consistent, well-defined business processes and rules. The applications contained with the Widget should have consistent and standardized API usage. For example, if an application has a completely different file structure or API method for each customer, a Widget will not work. In these situations, you can use the AtomSphere platform to develop a customized integration instead.

Widgets are Integration Applications

Widgets should be regarded as integration applications and should follow normal product lifecycle steps when designing, testing, release planning, etc. Before making changes, think of how they will affect current Widget install base and be sure to regression test.

End User Support

Although Boomi supports the AtomSphere platform and Widget framework, Widget developers are responsible for supporting their end users with issues installing or using their Widgets. Often there may be prerequisites including special configurations or customizations to the applications or environments for the integration to operate properly. Widget developers should provide appropriate documentation such as install/user guides and provide a means for end users to contact them for assistance.