Domino Interface

Architecting Microapps on HCL Domino with a mix of Vibe Coding, Event Bus, and Reimagination, Engage 2026

noreply@blogger.com (Domino Interface) — Wed, 15 Apr 2026 23:08:00 +0000

Next week I will be presenting the Breaking the Monolith: Architecting Microapps on HCL Domino session at Engage 2026 on April 21th.

Microapps are becoming more and more prevalent since the introduction of phone apps. Now with vibe coding many are creating microapps. They are great for personal productivity, but not so for businesses. Businesses require microapps to be secure and communicate with their other systems. So vibe coding an entire app can be problematic.

In this presentation, I will be combining a mix of vibe coding, no coding, AI and the event bus architecture that was presented last year at the October 2025 openNTF webinar to create a secure microapp architecture on HCL Domino.

Hope to see you there next week.

Abstract

While HCL Domino has traditionally been the home of monolithic applications, the modern landscape of low-code, no-code, and AI demands a more modular approach. Monoliths offer simplicity at the start but often result in scaling bottlenecks and 'brittle' codebases. This session explores the transition to a Microapp architecture—a strategy that unlocks faster development cycles, superior maintainability, and true scalability. Richard will demonstrate how to leverage Domino’s core strengths alongside a message-queue-driven design that was presented at October 2025 OpenNTF webinar to build flexible, independent application modules that are ready for the future of enterprise software.

What is a Business Workflow, Ancient Roman Perspective

noreply@blogger.com (Domino Interface) — Wed, 10 Dec 2025 14:12:00 +0000

With all the discussions about AI, automation and what it can do, there seems to be confusion about what is workflow? This has come up a number of times in our discussions with customers.

IBM defines it as:

"A workflow is a system for managing repetitive processes and tasks which occur in a particular order. They are the mechanism by which people and enterprises accomplish their work, whether manufacturing a product, providing a service, processing information or any other value-generating activity."

Basically it is:

Automation + Human Element = Workflow

AI can assist in improving the effectiveness, but it is the human element that determines whether the workflow best reflects the needs of a business.

Here is a brief fun video about workflow in ancient Rome from my colleague Rob Burton.

Presenting the October 2025 OpenNTF Webinar: Creating a Service Oriented Architecture Platform with Domino

noreply@blogger.com (Domino Interface) — Wed, 08 Oct 2025 21:21:00 +0000

Join me for the October 2025 OpenNTF Webinar. I will be presenting "Creating a Service Oriented Architecture Platform with Domino." This webinar will take place on October 16th at 10:00 AM CDT.

Abstract

Service-oriented architecture (SOA) uses software components called services to create business applications. In many cases, SOA platforms are distributed and utilize message queue or service bus to transfer data and requests between servers that handle different services. This approach allows one to scale up the platform when needed. The architecture of HCL Domino unfortunately was design before the concept of SOA and does not include message queue or service bus within its architecture. Or does it? In this session, Richard Moy will present how you can utilize what Domino already has and create your own SOA architecture based on Domino. We will also discuss why Domino provides some key advantages over other technologies.

To register for this webinar, go to https://attendee.gotowebinar.com/register/4158217087178039382

New release of iPhora Automate Now Available

noreply@blogger.com (Domino Interface) — Tue, 07 Oct 2025 16:27:00 +0000

We are pleased to announce that the latest release of iPhora Automate, our no-code user-driven automation platform. This release (2025091002) brings a new iPhora user experience with significant improvements in capabilities and features, along with faster performance. It also provides business users and other citizen developers with more capabilities for designing and automating their processes. Unlike other solutions, iPhora Automate is built from the ground up as a scalable business automation platform.

iPhora Automate applies a layered approach to process automation. For solutions that need the support of application developers, iPhora Automate provides new enhancements to the PhoraScript language and improvements in creating custom web service connectors. There are now more extension points in the architecture, which allow application developers to utilize PhoraScript in forms, ActionStreams and processes to better address the complex functionality required by some processes.

The initial loading time has been reduced by 30% to provide not only faster response but better performance.

The following improvements and new features include:

ActionStream Designer

Improved performance and new PhoraScript functionality

Form Designer

Support for Field Access Management based on user role

Users building an application can now control whether fields in a form are visible, read-only, or editable based on the user role.

Support for Field Access Management based on workflow task

This release allows users building a workflow application to control whether a field is visible, read-only or editable for a specific task.

PhoraScript

Forms can now include event-based PhoraScript code for the following events: save, saveNew

Grid Designer

Show Only Authored Content

A new grid setting that limits the listing to only documents authored by the current user.

Draft Workflow Content

A new grid setting that prevents draft documents (unsubmitted workflows) from appearing in the list.

Widget Support

User can now drag and drop certain widgets into a grid column.

Buttons

Users can now add buttons to download files or copy a value from a field stored in the associated document.

Progress Bar

For workflow-based grids, users can now add a progress bar to the grid to indicate the workflow progress of each document.

List Designer

Includes fixes to the importing UI interface

Navigator Designer

Improved error handling and information messages

PhoraScript

New commands and functions including:

@for / @endfor

@getField

@select / @case

@setField

@until / @enduntil

Improved syntax checking

This release improves the syntax checking process for errors and wrong commands.

Support for both global and application-specific scripts

Users with Application Developer (or higher) roles can now create scripts for use in specific applications or create global scripts that are re-useable within any application.

Process Designer

Improved support for Process Chaining

Business users can chain different process together without the need for an application developer to write custom code.

Asynchronous Trigger Support

Release 2025091002 brings in a new asynchronous triggering module that allows business users to include in their processes both asynchronous and synchronous tasks and events.

External Trigger - Task Support - Webhook

Individual tasks within a process or ActionStream can now be triggered externally by a webhook generated by an external web service

External Trigger - Process Support

Workflow processes can now be triggered and initiated by external triggers including:

External HTML Web Forms
Webhooks
Event Trigger by a Button

Service Connector Designer

Improvements and fixes to the Service Connector Designer

Service connector nodes are now automatically created and made available in the Process Designer node palette when a connector is published.

Fixes to the Endpoint Design Interface

To learn more, go to https://iphora.io

Integration of Microsoft VS Code with Domino, a Hack

noreply@blogger.com (Domino Interface) — Wed, 25 Jun 2025 14:47:00 +0000

Many components make up a Web application some of which includes CSS and JavaScript. Both CSS and JavaScript has rapidly evolved over the many years that Domino has been used as a Web Application Server. Unfortunately, the editors in Domino Designer has not evolved and you can not add and edit JavaScript ES6 code for example. The new Domino 14.5 I have been told allows one to edit ES6 JavaScript as a file resource, but not as a JavaScript script library file.

One of the most popular tools for editing CSS and JavaScript is Microsoft VS Code. There are some many extensions that you can download and work with many different programming languages. One very nice thing about Microsoft VS Code is that it is free and most developers are familiar with VS Code. In addition, it is much nicer of an editor than what is available in the Domino Designer.

There was discussions about VS Code integration with Domino at one of the past CollabSphere a few years ago. Unfortunately, that discussion never resulted in any progress in that direction.

As we developed our Dojo-based iPhora SPA framework many years ago, we found it frustrating not to being able to create and edit ES6 based JavaScript using the Domino Designer editor. So we search for a way to get ES6 level JavaScript into Domino.

The solution we discovered was importing the JavaScript file through DXL as file resources or as JavaScript file as part of Code elements in the script library. Using an external editor like Microsoft VS Code you can create, debug, minify and edit your JavaScript code. Afterward, you can import the code into Domino.

You can further extend this approach in creating and editing HTML and CSS and any text based data including JSON data. This approach works when creating and editing HTML, JavaScript and CSS from version Domino 9 and higher. I believe it works with older versions of Domino, but we never tested it.

In our sample database, we create web container documents for each component whether it is a JavaScript file, CSS file or HTML file. The HTML web container documents are the same documents with the rich text field that are read when the generating the web page as I shown in my previous blog post on DX Objects. For JavaScript and CSS files, they are merely placeholders that let the code to know what to process using DXL.

We have a profile document that provides the location of the HTML, CSS and JavaScript File on your local computer.

The local file system contains the files that you create and edit using Microsoft VS Code.

With Microsoft VS Code, you can create and edit based on the file structure that you need in a much more organized fashion. It has built-in ability to highlight missing or incorrect HTML tags or missing } or ) which help when coding.

In our Domino database view, we have a refresh button that corresponds to reading the local file, determining whether it is a HTML, JavaScript or CSS file and process accordingly. For HTML files, it pushes the HTML code into the rich text field of the web container document and for JavaScript and CSS files it pushes the code into Domino via DXL. The Refresh All button cycles through the document collection and processes all the files.

Summary

Though this is a hack, this approach plus the DX Objects provide Web designers and developers the ability to create Web sites and applications on HCL Domino using more traditional Web development approaches. The Web designer or developer does not necessarily need Domino experience to create the web pages. The Domino platform have many drawbacks when it comes to creating Web applications. However, with a little bit of imagination and hacking it is still one of the best Web application platforms.

This is the last of this series. Below are the links to the previous two blog posts and the sample databases.

https://dominointerface.blogspot.com/2025/06/out-with-old-in-with-old-building-your.html

https://dominointerface.blogspot.com/2025/06/engage-2025-visualize-your-domino-data.html

https://phoragroup.com/files/engagedemo.zip

Out with the Old, In with the Old, Building your Domino Web Application using DX Objects

noreply@blogger.com (Domino Interface) — Fri, 13 Jun 2025 17:47:00 +0000

Building a Web application on HCL Domino can be challenging because there are so many ways of creating a Web application. There is just no design pattern to follow or best practices. This is good for us who like to experiment, but bad for developers who just want to follow an official approach. You can use XPages, classic Domino Web with Pages, computing fields and computed text with formula language or you can create apps using REST APIs with LotusScript, Java , DAS (please no) , view read entries or even DRAPI as Paul Withers has demonstrated on his blog, https://paulswithers.github.io/blog/2024/08/15/xpages-web-1/

However, there is little talked about a very old technique that dates back to the beginnings when Domino became web enabled. As part of my data visualization session demo at Engage 2025, I used this technique to generate the web pages and dashboards.

This technique allows you to separate the form, data and business logic and creates a standardize design pattern for one to build web applications. XPages is the only other approach that comes close in enforcing a design pattern.

So what is this technique? A few years ago, I was looking for a way to create a blog for our web site that we had full control. Our Wordpress site was hacked even before we were finished because of vulnerabilities in plug-ins and later it was discovered that the large hosting company did not properly secure passwords. Go figure. But all too familiar.

I attempted to use the Domino Blog template as a replacement. However, trying to modify the Domino blog template was a journey of frustration and a series of futile actions. I truly believe in the separation of form, data and business logic and the Domino Blog template is another example to the contrary. As I dug deeper into the code there was a technique in generating web pages that I had not seen or hear of before.

I coined the phrase DX Objects for this technique. The approach is quite simple but powerful. Each web page is represented by a Web Navigator/Form pair that forms together as a Web page container. Located in each form is a Rich Text Field called html along with other CGI fields that you want to include. Put these all into a sub form.

The WebQueryOpen (buildWebPage) agent in the form is triggered when the user navigates to the Web page that has the corresponding name of the navigator.

The buildWebPage agent reads from a rich text field in a document with the html that you want to generate and display the web content. The document doesn't have to be in the same database. This allows you to secure the content and not allow web access.

For static web pages that is all you have to do. But more interesting is to use the concept that is found in the Domino Blog template that allows you to add complex business logic in building the web content, DX tag markups with the format of <$DX(something)$>. Now you can use any mark up you want, but for the demo I used the standard DX markup found in the template.

The goal is to replace the DX markup with business logic that you need and output the response to be included in the html generation of the Web page. The response could be html, text, JSON or others. That depends on your need.

In our example below we have the <$DX(CurrentYear)$> and it calls a LotusScript function that returns the current year. That is simple enough, that you can do with computed text in a Domino Page. However, what happens when you need to return a response that needs to lookup data even on a different server, process the data based on a variety of criterions. It maybe possible with formula language, but most likely not. In addition, you are still limited to 32K.

You can even use it to generate fetch calls to REST APIs to get data or info during the onload process.

And here is the results of demo01 page.

The advantages of creating your web page with DX Objects are:

Integration to more up-to-date Dojo/custom widgets or widgets created with React, Vue or other frameworks
HTML output that inhere to HTML 5 standards
Incorporate complex business logic
Add better access control for REST API based applications
The web content can easily excess the 32K limitations

For us at Phora Group, we have more advanced features that utilizes our LotusScript Flex Parser and our LotusScript HTML Parser to provide what we need for iPhora. However, there is no limit on what you can do. Only your imagination limits you. You don't have the crazy 32K limitation of computed text and other restrictions.

Performance wise the web page generation is in par with other approaches. It depends on the complexity of your business logic, but also how you get the content. If you are using a lazy load approach to retrieve your data, then the web generation will be extremely fast.

You can get the sample Engage 2025 databases that I created from my previous post.

https://dominointerface.blogspot.com/2025/06/engage-2025-visualize-your-domino-data.html

As a follow up to this post, next time we will cover how to have basic VS Code integration with Domino and create the HTML, JavaScript, and CSS all using VS Code and have it pushed into Domino.

Engage 2025: Visualize Your Domino Data with Open Source Tools Session Slides and Databases

noreply@blogger.com (Domino Interface) — Mon, 09 Jun 2025 11:43:00 +0000

Thank you everyone for attending my Engage 2025 session, Visualizing your Domino Data using Open Source Tools. Though I was up against some formidable sessions, I was surprised to have close to 30 attendees in my session. As promised, here is the PowerPoint presentation and sample databases and code.

I would like to thank Kris and Tom for an incredible event and for selecting my session for this year's event. They did a wonderful job in continuing the tradition of making Engage a premium event.

After Engage 2025, I spent a day visiting different sites in The Hague. The walk to the beach was a bit longer than I was told!

https://phoragroup.com/files/Visualize_Your_Domino_Data_with_Open_Source_Tools.pdf

https://phoragroup.com/files/engagedemo.zip

Our Journey in Optimizing and Bundling JavaScript for Web Applications

noreply@blogger.com (Domino Interface) — Tue, 29 Apr 2025 11:17:00 +0000

When building a web application, optimizing the loading process is important.

Previously, we used Uglify-ES and recently Terser to minify individual JavaScript files to help reduce the packages and load time.

With the next release of iPhora Automatic coming very soon, we wanted to significantly reduce the loading time needed and the number of HTTP requests handled by the Domino server.

Our struggles for the past few weeks have been figuring out the right JavaScript bundler that works with our Dojo Toolkit-based framework.

So why are we still using Dojo Toolkit you might first ask? Many have moved away from Dojo Toolkit, the granddaddy of JavaScript frameworks. Dojo provides us the core widget inheritance framework that is not just used for creating widgets like fields and combo boxes, but is used for building the many different app layers of iPhora not just statically but dynamically in real-time. It allows us to have a secure and fast SPA (single page application) architecture. We don't use any of the original Dojo widgets (Dijits). Each widget that appears in the UI is a custom widget object that is built specifically to work within our framework.

We first looked at Webpack which is probably the most popular JavaScript and resource bundler. IBM/HCL created the dojo-webpack plugin to bundle and minify Dojo Toolkit based applications and is still in use. We got dojo-webpack working with the latest version of Webpack, v5.98 and Dojo 1.17.3. But we had to upgrade to Node 18.20.8 and NPM 9.3.1. This reduced the loading time from 4.5 to 3.5 seconds.

Everything was great until a user try to navigate to different parts of the iPhora interface. Our iPhora SPA framework relies heavily on Dojo Require to dynamically load different parts of the UI. These modules may or may not exist when a bundle is created. In fact, for each instance the modules are totally different. So we went deep dive into the Dojo code and the dojo-webpack code and attempted many hacks. After many many tries, I was informed that one cannot dynamically load AMD (Asynchronous Module Definition) modules when bundling with the dojo-webpack plugin. Unfortunately, Webpack replaces all Dojo Require with their own Webpack require which only allow static modules. So frustrating.

Since Webpack does not address our requirements. We looked at newer bundlers like Vite and Pascal, but that was going to require a significant effort since no one has a Dojo plug-in. The biggest struggle was finding examples and answers to questions.

Since the Dojo Toolkit comes with a bundler, we went back to looking at it. However, much of the documentation and examples are very simple as usual and limited. Much of the content was older and incomplete.

The advantage of the Dojo Build framework is that it allows you to create independent bundles called layers which conforms to how we are using Require to load the AMD modules. It uses the Google Closure compiler which is much more restrictive than Uglify-ES or Terser (used in webpack). We have been using Uglify-ES and then later Terser for a long time, but Closure does a better job in finding errors.

With Dojo Build we are able to build a custom dojo bundle that includes only the dojo modules that we needed and the individual modules that contain our initial loader and custom iPhora widgets.

So here are the results.

Before Using Dojo Build Bundling

After Using Dojo Build Bundling

As you can see the load time drops from 4.40 seconds to 2.62 seconds. But more importantly is the reduction of HTTP request from 60 to 19. Why 19? One request is a cached request as a results of embedding an base64 image directly into the HTML page rather than requiring a http request.

As a result, you have better performance and able to handle more users per server instance.

I hope this post was informative especially for the HCL community since a number of products still use the Dojo Toolkit framework and as well as many products from other companies.

For us, the next step is to include the new Dojo Build process into our DevOps process flow and run it automatically as we create new updates.

Listed below are links that might be of interest to you to learn more. If you are attending Engage 2025 next month and have questions, track me down. And if you are interested in data visualization, attend my session on Wednesday at 2:30 PM at the The Hague Conference Centre New Babylon, The Hauge, Netherlands.

https://github.com/OpenNTF/dojo-webpack-plugin

https://dojotoolkit.org/documentation/tutorials/1.10/build/index.html

https://webpack.js.org/

https://github.com/vitejs/vite

https://github.com/kanaka/pascal.js/

https://terser.org/

I am speaking at Engage 2025 - Visualize Your Domino Data with Open Source Tools

noreply@blogger.com (Domino Interface) — Thu, 24 Apr 2025 14:12:00 +0000

If you are attending Engage 2025 and would like to learn more about how to visualize your Domino data, come join my session.

Wednesday, May 21 | 14:30 - 15:15 | 1.4 Breakout 2

De09. Visualize Your Domino Data with Open Source Tools

As they say, a picture is a worth a thousand words.

In the current data driven environment, having the ability to quickly visualize your Domino data is important. It allows you to discover hidden data patterns and trends that may impact important business decisions. There are a number of open-source visualization tools that one can use to create charts, graphs and plots.

In this session, Richard will discuss the different tools that are available and their advantages and disadvantages. Richard will show how to utilize these open-source visualization tools to help you effective visualize your Domino data.

To learn more and register for Engage 2025 go to https://engage.ug Hope to see you there.

Situational Apps - Spreadsheet versus No-code tools

noreply@blogger.com (Domino Interface) — Wed, 27 Nov 2024 02:41:00 +0000

As I mentioned in the previous blog post, the use of spreadsheets is the largest and number one method used to create situational apps. In part 2 of this blog series, we will do a comparison between using spreadsheets versus no-code/low-code tools to create situational apps.

Click on the link below to continue reading about this comparison.

https://iphora.io/iphora.nsf/blogentry?open=VQ34NT01

Situational Apps, What are They and Why They are Important

noreply@blogger.com (Domino Interface) — Fri, 15 Nov 2024 01:56:00 +0000

As the name implies, situational apps are on-demand apps that are created in response to a specific business situation (or need) that may arise infrequently. In general, the productivity gains attributed to a situational app are limited to only a few occasions a year and to few individuals. Therefore, most corporations are unlikely to devote significant resources to the development of such apps, and typical develop cycles may be so long that the situation itself will have expired before a professionally-developed app is ready.

To continue reading more about how important situational apps are go to our iPhora blog at:
https://iphora.io/iphora.nsf/blogentry?open=0F71X90S

The Beginning of Business Process Collaboration

noreply@blogger.com (Domino Interface) — Fri, 08 Nov 2024 13:33:00 +0000

We all think of online collaboration and business process automation as a modern concept that is only possible with the power of computers and the internet. My partner Robert Burton whom is somewhat of a history buff has an interesting history of business process collaboration that may surprise you. So, for some light and interesting reading open our latest blog post.

https://iphora.io/iphora.nsf/blogentry?open=ZXLW53VT

Learning How to Build your First Workflow App Using iPhora Automate - Basic

noreply@blogger.com (Domino Interface) — Tue, 29 Oct 2024 20:03:00 +0000

Now that you have downloaded and installed iPhora Automate - Basic onto your HCL Domino server, what's next. It is time to create your first workflow app using iPhora Automate - Basic.

To help you create your first app, we have created a library of training videos covering the basics of iPhora Automate and how to create an app. Each video takes you through a step-by-step process in building, assembling and deploying an app in iPhora Automate. Currently, there are 45 videos in this library with dozens of new videos in production that covers both beginner and advanced topics.

In addition to these tutorial, we have more training content coming soon that highlights the different types of apps you can create using iPhora Automate.

To access these videos go to:

https://iphora.io/iphora.nsf/courses

And start accelerating your business through automation.

Drive your Business Processes with iPhora Automate - Basic, Freemium Edition

noreply@blogger.com (Domino Interface) — Wed, 23 Oct 2024 19:46:00 +0000

We are pleased to announce the release of iPhora Automate - Basic, the freemium edition of our Domino-based automation platform. This limited edition allows you to create and deploy up to 10 workflow apps each can have unlimited flows for up to 10 workflow participants. Unlike some public cloud-based solutions, your flows never expire.

A valid HCL Domino license for the number of users is required. We recommend that you install it on a HCL Domino server running 12.02 FP4 or higher for Windows, Linux or IBMi.

Go to https://iphora.io to download your copy of iPhora Automate - Basic.

Instructions for installing iPhora Automate - Basic can be found here:

https://iphora.io/iphora.nsf/documents

To learn how to create your own workflow apps go to the iPhora Learning content:

https://iphora.io/iphora.nsf/courses

The iPhora Journey - Part 14 - Bringing All the Parts Together

noreply@blogger.com (Domino Interface) — Mon, 21 Oct 2024 20:00:00 +0000

Welcome to the final post of "The iPhora Journey".

Our goal as we started this journey was to take the HCL Domino platform that we loved for more than 25 years and redefining a web application running on Domino.

iPhora was created originally to allow us to provide a flexible platform for building secure web-based applications for our customers as part of our consulting services. However, it has now evolved into a platform that customers and partners can build their own solutions with the emphasis on user-driven workflow applications and process automation.

As an integrated application platform, you can build web applications in a variety of different ways with HCL Domino. In designing iPhora, we looked at the architecture of other platforms, identified their key features and determine how it could be implemented within the capabilities and limitations of HCL Domino and utilized its flexible architecture to the fullest.

We went through many iterations and versions always with a focus on continuous improvement. iPhora started with a pure JavaScript SPA/REST API architecture but as it evolved, we moved to a hybrid server-side generation/JavaScript REST API based architecture to provide better security and more control.

The entire architecture of iPhora is based on JSON which led us to create our own JSON parser written in LotusScript to meet our needs.

During our journey, we created a few things:

MongoDB like JSON document storage and data management architecture
A high performance LotusScript JSON Parser that any JavaScript developer could understand
An entire server-side generation language
A flow-based platform for creating apps, workflows and processes
PhoraScript a JSON-based scripting language
Flow-based ActionStreams
Dozens of custom Dojo-based widgets
An easy-to-use iPaaS platform
Data connector architecture
A new data security model that leveraged the existing capabilities of Domino security
A secure community-based platform for isolating and running applications and processes
A no-code platform for creating apps and workflow processes
Command JSON language to install and configure iPhora automatically onto a Domino server

For the past two years we have been focused solely on moving it from being a consulting tool to a commercial product. It has been challenging but fun.

As we end this journey, we are starting a new one. So, look forward to many announcements and things to come.

The iPhora Journey - Part 13 - Automating the Automate

noreply@blogger.com (Domino Interface) — Thu, 17 Oct 2024 12:04:00 +0000

This post was to be the final post of our "The iPhora Journey" series and summarize our entire journey and what we created. However, as I was preparing the final post I realize there was one item that I hadn't discussed. That is the experience of purchasing a product and installing it onto a Domino server. So, Part 14 will be the final post of this series.

Whether you are purchasing a product that you really want or paying bills online, purchasing services or products online has become the norm. For a new product launch we wanted this easy-to-buy and deploy experience.

Depending on the version of our product, different features are enabled. If a customer wants to upgrade the product to a more advanced version, the experience should be as easy as signing up for the upgrade, paying and the new features should available in the customer's installation. This is expected for most public cloud-based solutions. However, not so easy for private cloud/on-premises solutions.

Normally, it requires new downloads, configuration by the administrator, maybe installing new software and more configuring and testing. This can create a significant barrier to entry especially for SMEs whom may not have the resources.

So, our goal was to create this easy-to-buy experience for our private cloud/on-premises solutions.

You can breakdown the experience into three areas:

Registration and payment
Licensing
Distribution and deployment

The original plan was to create a custom solution or license a technology that is already available to make this work. But why, we already have an extremely powerful automation platform that we created, iPhora Automate.

It was time to Eat Your Own Dog Food.

In creating these processes, we discovered more gems that are available within Domino with some capabilities we never knew existed. But that is a discussion for a future blog post.

Each of the above processes involve a series of steps and approval processes. For example, during the registration process, a user fills out and submits a form with their information. This triggers an email notification to the user with a verification code that they enter into the verification form to confirm that they are who they claim. Upon verification, a number of asynchronous and synchronous processes are triggered. Some of these processes launch ActionStreams that create entries into the CRM App that we created and some create a user account into the customer portal where a user will get their license key and download the product.

The license key is then used during the installation process to determine what features are available to the customer. There are many other processes that are launched during installation to provide this smooth easy-to-buy customer experience that we all come to expect.

We are far from done. There are many aspects of the buying process that we are still designing and working on like connecting internal and external services in order to provide customers the best experience in purchasing and deploying our products.

Finally, next time the final post of "The iPhora Journey".

The iPhora Journey - Part 12 - Bring the Public Cloud Experience to your Private Environment

The iPhora Journey - Part 12 - Bring the Public Cloud Experience to your Private Environment

noreply@blogger.com (Domino Interface) — Tue, 20 Aug 2024 11:25:00 +0000

Public vs Private

In the digital automation market, which includes workflow and business process automation, there are literally dozens of no-code or low-code platforms available as public cloud solutions. They range from products like Zapier to Tray.io. In general, they all provide easy-to-use interfaces for assembling cloud services together in order to automate processes. Some are geared towards individual users and some towards enterprise businesses. However, aside from the ones intended for individuals or very small businesses, they may require some significant setup, configuration, and administration.

Public cloud-based solutions have a number of advantages for process automation. You can sign up and get access to these services within minutes and have a new process up and running in a relatively short time.

However, the majority of these solutions operate by routing your data (and the subsequent responses) through a series of different cloud services. Not only is your process dependent on the continued existence of those cloud services, your sensitive business data is now fully exposed to each one and subject to a different set of legal terms and conditions for each service. If any of those services becomes inaccessible due to a variety of factors, you have a critical operational failure within your business. In addition, the security and privacy of your data is only as good as the weakest link in that service chain. That is why more and more companies are opting for private cloud or on-premises solutions.

This brings us to private cloud and on-premises solutions, which have certain key advantages over public cloud solutions:

Data control
Data privacy
Data continuity
Data security

Unfortunately, most private-cloud or on-premises solutions require significant effort to install, configure, and manage. Updates and new features often require significant planning and coordination to roll out properly. Together, these disadvantages serve to create a barrier to entry for all but the most determined companies.

But what if you found a private solution that has the same ease of deployment, updates, and usage found in public cloud solutions? Then this barrier to entry is significantly lessened.

iPhora Vision

This is our vision for iPhora, a radically new product that combines the ease of deployment, updates, and usage typically found in public cloud solutions with the data control, privacy, continuity, and security of private cloud/on-premise solutions.

In bringing the public cloud experience to your private environment, we focused on four areas:

Product licensing
Installation and configuration automation
Simple one touch installation of applications and service connectors
Seamless one touch updating and upgrading

Product Licensing

Public cloud solutions offer a wide variety of licensing options, ranging from freemium to enterprise level. This allows customers to start using the services quickly, with little or no investment, yet making it easy to upgrade the license to handle more users and provide more features. iPhora uses a similar model: licensing is as simple as registering and paying the initial license fee (for non-freemium versions). License upgrades are handled the same way. We will cover licensing in more detail in a future post.

Installation and Configuration

As we all know, HCL Domino can be one of the most secure application platforms available. However, in order to ensure the security of web applications, there are literally hundreds of settings that have to be properly configured. Normally, the job of locking down a Domino web server is done by an experienced administrator.

Yet, given our focus on providing iPhora to the broadest possible audience, we have be able to handle customers who have no Domino administrator. As part of our quest to provide a simple, one-touch installation process that can get iPhora up and running within minutes, we had to find a way to fully automate every aspect of the installation/configuration process, while at the same time, being flexible enough to handle unique and/or changing requirements.

In some cases, iPhora is added to an existing Domino installation, and in others, iPhora will be the first and only Domino server they will ever have. Trying to account for both situations was a major challenge. The HCL Domino One Touch setup provided some of this needed capabilities, but it did not have the fine control that we required.

Another factor driving our installation approach was the need for having iPhora Automate available on the HCL SoFy platform. HCL SoFy allows users to spin up their own test versions of iPhora Automate within minutes. Achieving a fully automated installation and configuration process that was fast, complete, and reliable required a great deal of effort. We were successful and iPhora is available on HCL SoFy right now.

By the way, a future post will discuss about bringing your own solutions to HCL SoFy.

Adding applications and service connectors

In the language of iPhora, the automated workflow processes you create are known as apps and those apps can be connected to public/private web services using service connectors. In addition to building your own apps and service connectors, you can utilize an increasing number of existing apps and connectors. The goal is to provide the same simple experience that one finds in installing phone apps. So iPhora includes a public/private app and service connector store where apps and service connectors can be securely installed using a one-touch installation process.

Updating and upgrading

As we all know, it is much easier for public-cloud service providers to keep themselves up to date because they have full control of their platforms and the entire process is transparent to their users, while updating and/or upgrading a private cloud or on-premises platform often requires significant effort.

To make the iPhora update/upgrade process seamless and easy, even for private cloud or on-premise installations, we had to create a process that did not rely on Domino replication and operated entirely via HTTPS. The process had to be able to handle the core iPhora components, as well as apps and connectors. After many iterations, we finally achieved an update/upgrade architecture that was fast and reliable. As you can see below, the update process for an application is initiated with a single click.

Summary

The advent of public cloud computing has brought forward a new level of user expectation, not just in the design of the user interface, but also in the deployment and management of the solution. By bring the public cloud experience to your private environment, a key barrier to entry is eliminated, enabling companies to take advantage of the security and control offered by private cloud or on-premises solutions.

Next time in our final post of “The iPhora Journey” series, we will bring everything together.

The iPhora Journey - Part 11 - Integration to Cloud-based Services for Business Users Made Simple

noreply@blogger.com (Domino Interface) — Wed, 31 Jul 2024 12:01:00 +0000

The world of data processing is far different than it was 10 years ago. More and more of it is being done externally by highly specialized service providers. This enables companies to utilize the best available services -- without having to reinvent the wheel -- and incorporate those services into their core business processes. The resulting approach is also more agile, enabling companies to respond quickly to ever-changing business needs.

You can think of your business users as your subject matter experts. They are the ones who have first hand, daily experience with your data and processes. In a perfect world, they are the people who would be designing your processes, and in today's environment, that means taking full advantage of external services.

Your IT administrators are the gatekeepers. They are charged with protecting your business from threats and maintaining the security of your data. The last thing they want to see are your business users exposing the company's data to external services without their knowledge, involvement, or control.

There are many products on the market that allow individual users to include external services in their personal process flows. This means that the interaction is initiated entirely on the user's device and there is no way for administrators to reign in all the services being accessed. For security and governance reasons, admins would prefer that all these services are accessed on behalf of the business, and not individual users. That is one of the fundamental differences between a personal productivity tool and a scalable business solution. It would also reduce the stress levels of the admins to know that only authorized services are being accessed, that all communication is done securely server-to-server, and that all communication is logged.

In the past, that kind of server-to-server interaction with an external service required a lot of hours from a skilled application developer, taking it completely out of the realm of typical business users. It also greatly increased the cost, hence the demand for effective no-code and low-code solutions.

So how can you provide your business users with ability to create and maintain processes that integrate seamlessly with external data services, while maintaining the strict security and governance that companies need?

The iPhora Approach

Our goal was to create a framework in which application developers can create reusable connectors for internal and external services, connectors that can easily be consumed by business users in their own applications.

We learned the requirements and expectations of businesses during the many years we spent consulting in the field of process automation. Time and again, we had to create connectors for a variety of different data services using different approaches. Based on that experience, we identified the three primary components of a connector: an authentication and verification module, a module to handle the data transaction between the servers, and a UI component that handles the visual representation of a connector within a process flow.

Since the authentication and verification process varies from service to service, the framework had to be full-featured and flexible. Therefore, we created scalable approach that allowed the creator of a connector to select different fixed options, along with the ability to include custom options.

Our process flow architecture already had the ability to add custom action nodes, and this was extended to data connectors. Rather than hard coding the data transaction process (endpoints and webhooks), we wanted a fluid way that can be easily modified and updated, since service providers routinely change their specifications. The solution was ActionStreams. As you recall in our previous blog post, we talked about ActionStreams, which are reusable flows that can be used to perform actions within a process. We implemented the endpoints and webhooks of a service using ActionStreams, with all of the advantages of that format, including simplified data mapping and role mapping.

Many solutions like Zapier advertise integration to thousands of apps. However, the fidelity of each integration can be very limited. This is fine for individual users, but businesses often need more than just the one or two most popular endpoints. With the use of ActionStreams, developers can add as many endpoints and webhooks as needed, all of which can be incorporate into the workflow process of your business users.

This granular approach also extends administration. There may be cases in which your business does not want to allow certain endpoints or webhooks. So, administrators have the option of turning on only the parts of a service that they need, as shown below.

We are currently expanding our list of supported connectors, ranging from financial to social media. We would like to hear from you. Which services are most important to you?

We are getting near to the end of our iPhora Journey series. Next time, we will talk about bringing all things together.

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

noreply@blogger.com (Domino Interface) — Sun, 14 Jul 2024 15:06:00 +0000

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.

ActionStream is a trademark of Phora Group

The iPhora Journey - Part 9 - Flow-based Programming for Your User Interface

noreply@blogger.com (Domino Interface) — Wed, 08 May 2024 12:50:00 +0000

In general, for non-software developers aka business users, an Application is one single object that they download and install onto their device whether a phone or laptop. It may also be a solution that they can access from their web browser. It may contain a series of screens that they navigate between as they use it. The Application most likely includes many components working in unisons some in the background and some generating the visual interface that they see.

The Application may have many screens and visual design elements. For example, you might have a dashboard that shows aggregated data, a grid that list documents, or a form that users will use to fill out data.

Many solutions layout out the different screens using a tree structure that shows the relationships between screens. Usually, you build the connections between the pages by selecting actions within a screen. For example, in Microsoft Power App. the tree structure looks like:

However, we wanted a more visual and intuitive way for any user to build their solution allowing them to connect the different parts of the solution as easy as analogous to building with Lego blocks.

We came up with the concept of AppBlocks which represented common components of an application like a form, grid and page. Each is a design element with pre-defined properties and behavior on how they interact with other AppBlocks within an application.

Originally AppBlocks utilized a simple block-based interface with pre-assembled components based on given templates that users might commonly use. This was somewhat restrictive, but worked well. This worked fine until the user wanted to make additional changes or enhancements to the design.

iPhora AppBlock version 1

Therefore, we looked for a more flexible approach where users could utilize a number of predefined design templates, but also allowed them to visually customize the design of the application without the need for developers to create code. They could even start from scratch with no pre-defined template.

Since we were already using the mxGraph library to allow users to visually design and create their own processes, we wanted to see if was possible to use it for creating the user interface. A user interface and how a user navigate throughout an application is essentially a flow. In fact, developers have used Node Red to create dashboards, but only as a single design element.

But the trick would be again be how to treat each component as a black box with interaction with between AppBlocks governed by a common bus that facilitated communication. In this case, the communication was not only data but user interaction.

Unlike the process node elements, AppBlocks, were much more complex in nature. AppBlocks themselves contained a variety of design elements within themselves and we needed to keep track of the different design elements within an AppBlock. Again, the flexibility of using JSON to represent objects and design came to light.

iPhora AppBlock version 4

It took almost 6 months, but we were able to get it working. As shown above a user can easily visualize the design of the application that they have created making it easier for them to create and edit applications. Does this approach work for all applications and the answer is no. However, it provides 90% of the need.

Now that we have the tools to visually create applications and processes for which business users can use to automate their processes, we needed a way for iPhora to go beyond basic workflow. Something that business users could easily utilize to scale and handle complex workflows and processes. Next time, iPhora ActionStreams.

Introducing iPhora Automate - User-driven Automation for Your Mission Critical Processes

noreply@blogger.com (Domino Interface) — Mon, 22 Apr 2024 06:02:00 +0000

By trade, I am an Electrical Engineer with a specialty in Microwave Engineering. And as part of my education, I had to take courses in process and industrial engineering which involved process optimization and automation. I hated these two courses and naively thought I would never ever use the information that I learned in these two courses. I only had interest in the technical aspect of engineering and with my first job out of college that is what I did. Never did I ever thought that I would spend the past 20 years focused on stuff that I hated in college.

The concepts of iPhora came out of issues that we encountered as we rapidly grew another business many years ago from which spawn our business process automation business which we have been doing for the past 20 years.

For the past few years, we have been transforming our consulting service platform into a commercial off-the-shelf product that focuses on the business user as the target audience. We would like to introduce iPhora Automate, User-driven Automation for Your Mission Critical Processes is now live on HCL Sofy.

iPhora Automate on HCL SoFy

The iPhora Journey - Part 8 - Flow-based Programming

noreply@blogger.com (Domino Interface) — Mon, 15 Apr 2024 12:12:00 +0000

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 are some new developments in the programming world that we need to take into account... and no, I'm not talking about AI.

Let's start with the basics:

Based on recent surveys, 60 to 70% of all enterprise applications are associated with implementing business processes, and a simple definition of a "business process" is that it is a series of tasks that need to be performed by an organization to achieve a defined business goal.

In general, if the business process involves interaction with humans we refer to those processes as workflows.

Simple business processes are usually linear and may involve only a few steps and decisions. However, more complex processes are often non-linear and involve the launching of other processes or sub processes. They may also involve data or data processing requests to external services.

If the business process needs to occur frequently, it is best to automate it. This can be achieved via software programming using any of a multitude of available languages. For example, over the past 30 years, literally thousands of workflow applications have been built by Domino developers and many of them are still in use today.

However, the core business process itself is fluid; it is always changing. This is because the business environment itself changes over time and competitive pressure means that improvements are always necessary. Unfortunately, constant tweaking and adjusting of all process across an entire organization is a tremendously expensive proposition, so much so, that most processes are rarely touched once they are rolled out.

When we first built iPhora Foundation to automate workflows and processes for our customers, it was XML-based and functionally similar to how typical Domino-based workflows operated. But that approach did not allow for the flexibility that we needed to handle non-linear processes, and of course, if any changes or improvements were needed, the customer has to pay our consulting rates to get it done.

But that experience taught us a great deal. We knew we needed to develop a different approach. Non-linear processes involve asynchronous triggering of incoming and outgoing requests. It may involve a mix of user-based and automated actions, as well interaction with external services.

At the same time, the industry has since moved in the direction of no-code programming, where the developers are the business users themselves. The goal of this approach is to make the resulting applications more suitable to business needs of the users and to reduce the costs associated with creating and maintaining applications. There are now hundreds of no-code and low-code solutions on the market, most of them utilizing the concept of flow-based programming. A well-known flow-based tool is Node RED, which is designed for low-code and pro-code developers.

From Wikipedia, flow-based programming is defined as.

"In computer programming, flow-based programming (FBP) is a programming paradigm that defines applications as networks of black box processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.

FBP is a particular form of dataflow programming based on bounded buffers, information packets with defined lifetimes, named ports, and separate definition of connections."

You can think of it as creating a flowchart with each node performing a specific business operation. Each node is a black box and should be reusable.

So our goal was to transform iPhora Foundation to utilize a flow-based model of process automation. This turned out to be a much more daunting task than we originally imagined. Most flow-based solutions on the market use a simplified security model. Since many of the processes that our customers needed involved sensitive data, we wanted a higher level of security, where the operation of each node is allowed or disallowed based on workflow roles, which could be evaluated in real time based on a number of criteria.

We needed a framework that would allow us to create different types of nodes with defined business logic and make them available for users to build their processes. But how do you get these different nodes to communicate with one another? To handle this we created a persistent common bus that allowed the nodes to communicate and transfer data between themselves as long as the process was active. We decided that the communication pathway should be in the form of JSON objects. This allowed for a standard data packet structure that could handle any situation from the simple to the complex. Since we had already developed a LotusScript-based JSON parser, this was a no brainer.

We started with 5 basic nodes:

Start
Task
Notification
Conditional Branching
Complete

With these nodes, business users can easily automate a basic workflow process. To handle more complex processes, we came up with dozens of additional nodes, including a node that can handle independent threaded processes called ActionStreams. (We will talk more about ActionStreams in a future blog post.)

We are constantly coming up with new nodes. Some of them require a low-code or pro-code developer to design and build, but the resulting node can then be consumed by business users in their own applications, giving them a wealth of business logic that they can include in their designs with no coding on their part.

The other part of the puzzle is the user interface. Our target audience of business users requires an intuitive, visual interface to assemble their processes. Luckily, we were able identify a great open source solution, mxGraph, that provided the visualization that was needed. If you have ever used a great little product called draw.io to layout a flow diagram, it uses the mxGraph library.

But setting the goals and selecting the tools was the easy part. Creating an effective, easy-to-use interface to our node processing engine was the majority of the battle. After many tries and redesigns, we were successful, and this design is now incorporated into our iPhora AppBuilder solution.

Flow-based programming is a powerful methodology for creating applications. It forces you to think in terms of reusable independent building blocks, and the result is reduced development time and less need for skilled developers..

Next time, we will take flow-based programming to a different level, The iPhora Journey - Part 9 - Flow-based UI 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

CollabSphere 2022 Presentation: COL103 Advanced Automation and Cloud Service Integration for your Notes/Nomad Applications

noreply@blogger.com (Domino Interface) — Thu, 27 Oct 2022 06:39:00 +0000

Our presentation for CollabSphere 2022. Learn how to quickly add workflow automation into Notes/Nomad applications using No-code tools that can utilize cloud-based services.

The iPhora Journey - Part 7 - Transforming Domino with Microservices

noreply@blogger.com (Domino Interface) — Fri, 16 Sep 2022 22:04:00 +0000

Most of the concepts that we have been talking about in our iPhora Journey are neither new nor revolutionary. Collectively, they merely represent the current state of the art in designing web applications.

In other (i.e., non-Domino) platforms, you would need an array of services each running on a separate server, and you would have to build the integration between the different components and maintain security between all of those components. With virtualization and containers all of the necessary services can now bundled into a single installation, which is helpful, but the integration of those components can still be fraught with issues, especially compatibility between different versions of those services.

With Domino all of this is taken care for you: authentication, directory services, security, web services, and database services are all tightly integrated in a single server, which is an advantage that no other technology offers. While Domino has its quirks and does not support many of the latest features, hopefully HCL will be addressing those in the near future. Even as it stands right now, the simple addition of nginx as a proxy to Domino addresses most of the deficiencies.

The iPhora platform is built on Domino, and in doing that we take advantage of the inherent integration of the Domino services. But we also incorporate design methodologies that are usually associated wit non-Domino applications. With this approach, iPhora has the capabilities and features of a modern web application, but all it needs to run is a single server with the most minimal of hardware requirements. We challenge any vendor to be able to do everything that iPhora does on a single box as small as this.

Creating a modern application is not solely about using latest technology to build the application. Well-supported technologies with a long term commitment to maintenance are always preferable to the latest design fad. The important question is what you do with that technology?

The iPhora concept evolved over the span of 15 years, as we developed applications for organizations, both large and small, and gained experience with how companies handled their internal business processes. Step by step, we abandoned the more monolithic approach normally used when creating Domino applications, for a more fluid and plug and play architecture. Eventually, we wound up with a service based and loosely coupled architecture, a microservice architecture. It should be noted that this applies to the iPhora components that we developed, not to the underlying Domino services.

Wikipedia defines microservice as:

"A microservice architecture – a variant of the SOA (service-oriented architecture) structural style – arranges an application as a collection of loosely-coupled services. In a microservice architecture, services are fine-grained and the protocols are lightweight. The goal is that teams can bring their services to life independent of others. Loose coupling reduces all types of dependencies and the complexities around it, as service developers do not need to care about the users of the service, they do not force their changes onto users of the service. Therefore it allows organizations developing software to grow fast and big, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API."

Using the programming tools available in Domino, we were able to build a microservice architecture that passes data in and out using a common bus and transport schema. Each microservice is an isolated black box with only input and output.

Remember that in a previous blog I mentioned the importance of the JSON format and the ability to quickly process JSON. The reason is that the data transport layer between microservices is all JSON. By having all input and output defined as JSON objects, we achieve a standardized and easily extensible communication layer. This allows microservices to be independent and reusable by multiple services and processes. A typical process can chain together a series of microservices to accomplish a specific and highly complex task, as opposed to writing a custom services to accomplish the same thing.

But how do you connect these different microservices together to create your application? This leads to our next discussion next time, flow-based programming.

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

The iPhora Journey - Part 6 - An Application, Rethinking and Redefining

noreply@blogger.com (Domino Interface) — Tue, 06 Sep 2022 23:52:00 +0000

In our previous articles, we discussed the advantages of using JSON in applications and the importance of being able to effectively process JSON. This leads to the interesting question: what exactly is an application, and the answer to that question may differ depending on who you ask. Most people today would assume you are referring to a phone app, and even then there are wide range of options. A college student might think of apps like Tiktok or WhatsApp, and a person looking for a significant other might automatically think of Hinge or Tinder. All of these people would be able to provide you with multiple examples of apps, and they might be able to list some of the common features of an app, even if they do not understand any of the technical details.

In general, a web app today consists of the following four modules, even if the technical details may differ tremendously from app to app:

User interface (UI)
Database
Business Logic
Security

Now, let's consider what an app is in the traditional Notes/Domino sense. Here, an application still consists of the same four modules, but everything is mixed together (actually smeared-together may be a better term), as opposed to being separated. A Domino application consists of one or more Domino databases, and access and security is defined within each database using ACLs. This is true for both Notes client and Web-based applications created on Domino -- so far, so good. However, when it comes to the UI and Database modules, Domino uses the concept of a form, which defines both the user interface and the data structure for storage, modules that are typically separated in more modern apps.

Moreover, the business logic is programmed directly into the actual UI components all over the form. Even something as simple and basic as controlling what UI elements are visible (i.e., hide-when formulas) requires that the programming logic is dispersed throughout the form and may be associated with each and every UI component.

This approach can work for stand alone applications or situations involving only a few applications. However, as the number of applications increases, providing the infrastructure to effectively create and manage the applications and user access becomes more and more difficult. This is very true for Domino applications because the business logic can be implemented in so many different ways and in so many different places.

The complexity of Domino applications tends to increase even further because the data is distributed throughout multiple databases using different data structures. The more different forms an application uses, the more views are needed and the more indexing is required, resulting in the need for more storage space.

So our primary goal was to structure iPhora to follow a modern application architecture, but still provide the extensive data security one expects from Domino. We wanted to be able to build and manage hundreds of applications with the same ease as doing it for one application. Almost all of the development projects that we have been involved with so far began with one critical application that eventually expanded to dozens of related applications, each with different sets of users and different ACLs requirements. For one customer, that one initial application grew into 50 applications and over 100 processes, each with different roles and user access requirements and all accessed and managed within a single instance of iPhora. Yet even as more and more applications were added, no additional Domino databases were needed.

An iPhora installation uses only seven Domino databases, each serving a specific purpose within the iPhora architecture:

API / GateKeeper
Attachment Store
Business Logic
Data Store
Logging
UI Interface
User Profile

In other words, there is no longer a one-to-one relationship between applications and Domino databases. Any number of applications, including widely different types of applications, can be accommodated using this structure.

Since data security is of the upmost importance for iPhora, it was extremely important that users never have direct access to the data, which is contrary to a traditional Domino application. We wanted all of the databases to be totally locked down. Our API consists of LotusScript agents that interact with the data according to strict protocols. In general, the only database that users interact with is the database that holds those agents, and the UI interface. The other databases cannot be opened using Domino URL commands.

Since data is stored as JSON, the data store module utilizes a single Domino form to store all records regardless of the application, although the fields may different from one form to another. Any attachments that are uploaded into a data store document are actually stored in a separate attachment store database which also utilizes only one single Domino form. With DAOS, we can handle 1 TByte of attachments and if more are needed, we just can simply add another attachment store.

For companies that already have data in Domino databases, iPhora has the ability to read and display data from other Domino databases, including databases that are structured in the traditional Domino way. The only requirement is that form structure needs to be defined and added to iPhora.

In conclusion, by re-thinking and re-imagining what an application is in Domino, Domino becomes a scalable application platform on which to build and run secure applications that utilize a modern design framework. The advantages of a structured and scalable application architecture become apparent as one moves towards utilizing no-code/low-code tools to build applications, something we will consider later in this series.

How we access and communicate with external services including non-iPhora Domino applications is the subject of our next discussion, Microservices and Naoservices

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