In the last post, we discussed the use of flow-based programming for creating user interfaces. In this post, we introduce the ActionStream, which is the the foundational flow-based component in iPhora.
A workflow process consists of series of nodes that are connected together. iPhora AppBuilder supports many different types of nodes, including task nodes, notification nodes, and branching nodes, as well as a wide range of action nodes. A sequence of actions that are connected together is referred to as a flow.
During our 20+ years of experience in automating processes, we encountered many situations where the same repetitive flow occurred within different processes. Therefore, it would be beneficial if it were possible to reuse the same flow in multiple processes and applications. This led directly to the development of the ActionStream, which is a reusable sequence of action nodes, in other words a reusable flow.
Originally, ActionStreams were just a way to quickly implement custom capabilities that could then be added into to the node palette and utilized by business users in their processes. But as ActionStreams evolved over time, we realized that they could do much more. They became the foundational layer for iPhora. In fact, certain parts of iPhora, such as service connectors, are entirely made up of ActionStreams.
So, what is an ActionStream?
An ActionStream is a process flow that consists of a series of action nodes. By assembling action nodes together, very complex actions can be implemented. The resulting ActionStream is then given a name, and it can then be reused in different processes. It is possible to create ActionStreams that are truly global in scope, meaning they can be used in any process, or ActionStreams that are limited to only a specific app.
The closest analogy in the programming world is a NodeRed subflow, where an entire subflow is represented by a single node. Unlike NodeRed subflows, ActionStreams are stand-alone and can be reused in multiple processes and workflow applications. ActionStreams can have their own assigned access control settings, but they are also able to inherit the security settings of the parent process.
An ActionStream can include other ActionStreams within its flow. It is also capable of launching a separate workflow process. For example, you may have a form that visitors can fill out on your website to submit information. Upon submission, a form post ActionStream can trigger an entire workflow process that checks the submitted information, adds that information into a database, and notifies the task performer that there is a pending task that needs their attention.
ActionStreams have access to the field data associated with a process. However, the ActionStream itself may use a different set of internal names to refer to those fields. Because of this, a field mapping tool is available whenever an ActionStream is pulled into a process (or other ActionStream). The mapping tool makes it easy to associate the process fields with the ActionStream fields.
Just like a workflow process, you design and build an ActionStream using the visual designer in iPhora AppBuilder. Only users with developer and higher access can create/modify and publish ActionStreams. After they are published by the developer, ActionStreams can be accessed from the process design palette for consumption by business users when building their workflow applications.
As I mentioned, ActionStreams have evolved over time, and they have now become the basis of our flow-based architecture. They provide a consistent and well-structured environment for developers to create the specialized business objects that they need. As a company grows its library of ActionStreams, it provides more and more capabilities that business users can incorporate into their processes.
Next time in our iPhora Journey, we will focus on external service connectors, which form the REST API interface to cloud-based services.
The iPhora Journey - Part 9 - Flow-based Programming for Your User Interface
The iPhora Journey - Part 8 - Flow-based Programming
The iPhora Journey - Part 7 - Transforming Domino with Microservices
The iPhora Journey - Part 6 - An Application, Rethinking and Redefining
The iPhora Journey - Part 5 - Dammit Jim, I'm a LotusScripter not a JavaScripter
The iPhora Journey - Part 4 - JSON is King - The How
The iPhora Journey - Part 4 - JSON is King - The Why
The iPhora Journey - Part 3 - Creating an Integrated UI Framework
The iPhora Journey - Part 2 - Domino, the Little Engine that Could
The iPhora Journey - Part 1 - Reimagining Domino
ActionStream is a trademark of Phora Group
Comments