Skip to main content

The iPhora Journey - Part 10 - ActionStream - the Heart of iPhora

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

Post a Comment

Popular posts from this blog

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a
Post a Comment
Read more

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select
Post a Comment
Read more

The iPhora Journey - Part 3 - Creating an Integrated UI Framework

The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework There are many ways to create the user interface (UI) for a web application. The HTML page could be created on the server and then pushed out. It could be static with the data generated on the page by the server with JavaScript, providing a more dynamic experience, or the server could generate new HTML content to update portions of the web page. XPages or PHP are good examples of this. Another method is to have the web page partially generated by the server and have JavaScript build the rest of the HTML by pulling data from the server via an API. This is the approach used in the Single Page Application (SPA) model. In all cases, it is still dependent on the web server technology being using.  As mentioned previously in this blog, XPages is dependent on complete integration between form and document, which e
Post a Comment
Read more