So, I have been a busy boy when it comes to Mobile Flows. Last year, I wrote a neat article all on Mobile Flows.
This year, I had the pleasure of bringing it all full circle covering mobile flows at VMworld in two sessions. I have been a huge fan of mobile flows for quite awhile especially the OOTB (Out-of-the-box) connectors which were so easy to do. Just check out my video as a reminder:

Anyways, Mobile Flows are being retired and the new shiny Experience Workflows enter the fray. Today, we are going to introduce everyone to Experience Workflows along with setting up Adobe Sign. This is part one of a two part series where we cover some of the basics and provide some solid overviews. Lets get the show on the road!

Setting up SSO for Experience Workflows

I felt like a good place to start is on the SSO setup. I would be remiss if I didn’t mention the nice documentation they have for getting started. Not a huge deal overall, but I think providing some small guidance on SSO is helpful.

It’s pretty simple. You just grab the ID out of the Hub Services > Experience Workflows as you see below and set stuff up!

Enjoy the Demo so you can get into Boomi and make the magic happen:

Setting up our First App: Adobe Sign with Experience Workflows

Setting up the first application was an interesting experience. The major callout is they finally have actual documentation for the most part for setting up OOTB connectors, which was not true with Mobile Flows. Luckily for me Ashka Vakil at VMware connected me with some developers a year ago. This time around, the setup is relatively easy.

A few caveats to point out:

• Users no longer need to opt in via the “Notifications” section in the Hub. This is entirely powered now by the “User Groups” section as you will see in the video.
• Not All Mobile Flows has been ported. I’m not sure what the future holds there, but currently its:
  • Adobe Sign
  • Coupa
  • Salesforce
  • WorkDay
  • Concur
  • Jira Service Desk
  • Service-Now
• Your true value will be on what you choose to invest on having custom connectors built
• You can probably modify the hero cards with a bit of time and patience, but its a major rabbit hole.

Enjoy the video below that will show you how to setup Adobe Sign with Experience Workflows:

Time to Checkout the Boomi Console

Once you enter the console, you feel a true sense of being overwhelmed. The deeper you dig into the nice little apps that VMware built for us the more you fill with despair. At least, that is how I felt. You get buried under a variety of types of things that we will discuss in the next section.

The great highlight with the Boomi console is you have so much more access to logs and data to troubleshoot issues that would normally require engineering/developers to get the info you need to break fix your issues:

The Building Blocks of Boomi

In Adobe alone, we have these different things of components that make up our Adobe Sign integration. Let’s discuss them a bit in detail.

Boomi Connectors

Boomi Connectors get data from and send data to processes. They are basically the endpoints of the processes. You have a number of built-in connectors for various applications and things like a basic HTTP client.

Connectors have two components: connections and operations. You can think of connection as the “where” and the operation is the “how”. They are a major player for Boomi as they will determine the type of data, connecting to it, and the result. Dell has a nice table below that covers a good way to delineate it:

Connector Type	Connection	Operation
Disk	Local directory location	File name, file filter, whether to delete files after reading them, and how to name the files
FTP	FTP host name, port, user name, password	Remote directory, file filter, and whether to rename or overwrite files
Database	Database host name, user name, password, connection pool settings	How to batch or commit and the profile to use (which contains the actual SQL statement)
Salesforce	Salesforce account user name and password	Record type, action (query, create, delete, merge, update, upsert), filters, and sorting
QuickBooks	(For Desktop edition) company file name, file mode	Record type and action (query, add, modify, delete)

Boomi Document Caches

Document Caches let you index Boomi documents in integration processes. This is what lets you run Experience Workflows so effectively by caching documents and referencing them later on in processes/subprocesses. You can hold it in memory and run things more efficiently.

Caching will also provide data persistency across branches, which is a good data best practice. Every document is an entry in the cache, which means documents will sometimes be split prior to allow you to retrieve exact the data you need. Caching also respects parent/child relationships bringing in consistency. One thing to be wary of is the cache only exists for a single execution. Feel free to check out the video here on document caching.

Some of the use cases around caching are:

• Combining documents from different sources
• Working with incomplete documents where you need to bring data together from multiple sources to solve your requirements.
• Processes that need to query the same data multiple times.
• Working with SOAP messages containing MIME attachments (attachments are stored in cache)

Boomi Profiles

Profiles describe the format of documents that ingested or egressed out of a process. It contains field names, delimiters, column positions, data types, lengths, and more.

We see profiles used in maps. An example is how you will map an XML document to a flat file, create a profile that is the same as that XML file’s layout, and then another profile will match the flat file itself. With the flow of your integration profile parameters are used for the Decision, Cleanse, Program Command, Message, Route, Document Properties, and Exception steps.

One of the nice things about profiles is you can import one from an existing file like database tables, JSON files, or XML files. You also have to be aware that re-importing/updating profiles has a cascading effect to its connections in maps where its used. Boomi is smart enough to try to match profile elements, but its not an exact science. Naming conventions matter as well, which will break links such as renaming a file in a path.

Profiles have many types, which I will show you direct from the Boomi documentation:

Name	Description
Database	Database profiles can be Read and Write. A Read database profile can execute SELECT statements or stored procedures against a target database. A Write database profile can execute an INSERT, UPDATE, DELETE or stored procedure against a database.
EDI	An EDI profile describes a delimited or positional file that meets ASC X12, HL7, EDIFACT, TRADACOMS, or User Defined standards.
Flat File	A flat file profile describes a file that contains either delimited or positional data. An example of a flat file is a comma separated (CSV) file.
XML	An XML profile describes a file that meets the W3C Standard for eXtensible Markup Language.
JSON	A JSON (JavaScript Object Notation) profile describes a file that represents simple data structures and associative arrays. JSON files are based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999.

You can see an example of a profile below:

Boomi Maps

Boomi Maps convert data between layouts or formats. You will see in the diagram below how it shows a document is laid out and its desired format. In the middle we have source and destination profiles facilitated by the map to transform the data.

Let’s check out an example of one of these Boomi Maps:

Boomi Process Shapes

Process shapes are the individualized steps that make up Boomi processes. They dictate how the process retrieves, modified, directs, and sends data from source to destination aka data flow. Those of you with network backgrounds will get that concept pretty well.

Shapes are distinct and often connect to other components we discussed earlier. You can see a collection of some of the shapes below:

Boomi Processes

Processes are the lifeblood of any Boomi integration. They contain the various shapes that decide how data execution happens. It is your typical workflow that moves record types from applications to other applications.

You will find they’re made up of connectors (from scratch and pre-built), execution shapes like Maps, Set Properties, Retrieve to Cache, etc, and Logic Shapes like Branch, Route, Cleanse, Try/Catch and more. You build processes to account for all scenarios and power your integrations to deliver business outcomes.

It’s best to check out the table below to see some of your potential options:

Now that we have covered that, let’s look at what a finished process looks like:

Boomi Process Properties

Process properties are sort of like a PList. They’re name/value pairs used to store information that is helpful with your integration. You store the properties to retrieve it later on in your integration.

There are two types: (1) Process Property components and dynamic process properties. Process Property components are reusable components that are a collection of properties whereas dynamic are created at the time they’re needed. We do have a few challanges like two independent processes running simultaneously do not have access to the same properties in memory.

Your integration can retrieve them from parameter value list from most process shapes, the get process property map function, and custom scripting or custom scripting map functions. You can set properties via the set properties shape, set process property map function, or custom scripting steps. Let’s check out an example below:

Final Thoughts on the Aspects of Boomi

It’s honestly relatively complicated overall, but with some solid work we can make progress and build something great. Boomi offers some decent documentation here that teach you about the things that make Boomi what it is. Let’s cover a demo showing how card creation (the notifications you see in the hub) happens.

Adobe Sign Card Creation

The thing that everyone mainly cares about is how can we enhance those notifications that people get in the Intelligent Hub. I thought it might be useful to take some time and see how it all comes together. It is certainly a complicated process, but it teaches you a ton about structured data and how things come together somewhat gracefully:

Final Thoughts

I have to admit it takes a TON to make me feel overwhelmed. Boomi does that without hesitation. I mean good god!

I think the interesting play with Experience Workflows is how much money/resources will companies be willing to put into making this amazing. It’s going to be a PSO offering, partner offering, or developer investment that will be substantial. I love the potential of it and the pro’s are pretty good. Let’s check out some Pro’s and Con’s:

Pro’s	Con’s
1. No more infrastructure hosting 2. You can modify stuff VMware Built 3. Tons of OOTB connectors that you can build custom integrations on. 4. Deprecated mobile flows are still around so no major rush 5. Access to logging and code-level access to tweak and fix issues	1. Major investment to build new connectors 2. Upkeep is challenging and will really require talented engineers to achieve. 3. A new license is required (Workspace ONE Experience Workflows Add-On License) with a MSRP around $48 per user with 1000 minimum users.

As you can see above, Boomi is a great investment, but it is truly an investment is the user experience. I think with the right support and some attractive engagement models, it could be very beneficial for WS1 customers provided they can get over the new pricing structure.