OpenText Process Suite becomes AppWorks Low Code

“What was formerly known as Process Suite is AppWorks Low Code, since it has always been an application development environment and we don’t want the focus to be on a single technology within in.”  – Dana Khoyi, architect of OpenText’s Process Suite

That pretty much sums up the biggest BPM positioning/branding announcement at OpenText Enterprise World 2017 this week. BPM is dead, long live low-code application development? Note that AppWorks is the name used for all OpenText developer tools; the technical developer APIs and access points, plus this low code product which is really a separate product.

Khoyi and Kelli Smith (who did the main stage People Center demo on Tuesday) led a session on the last day of Enterprise World to show how Process Suite AppWorks is used to create applications, starting with defining composite entities (business objects made up of multiple pieces of data), then UI constructs including forms, dashboards and lists. Because process and content are built into the environment, there are easy building blocks for content lifecycle, activity flow and history. Declarative rules are supported — triggered on conditions, events or user actions — and dropping out to a full process model for more complex flows and events. They also have a development framework for building customizable applications that persists customizations separately from the application and merges them at runtime, allowing a new version of the core application to be installed without discarding the previous customizations, although obviously you’d want to test and might require some minor retrofits.

Application development starts by defining the core entity for the application (think process or case instance class) then add properties (data fields) and building blocks: forms to edit and display those properties (as well as built-in properties such as state); lists that can be worklists or reporting artifacts; and layouts, which are essentially the application UI screens and can include the previously-created forms plus actions, breadcrumbs, and related content. Data/content security and access/update conflicts are handled automatically on the forms/layouts based on underlying security definitions. Apps that are created can be published immediately to run; these can be moved as packages between testing and production environments although it’s not clear that there’s any versioning or automation around that, so likely some manual governance is required.

Other building blocks that can be added to an application include:

  • A history log that maintains a complete audit trail of everything done during the instance including field-level data changes
  • A discussion for collaborative chat/comments on an instance
  • Content, which can be files/folders that are attached to the case instance using a local document store or other content store via a connector or CMIS, or a businses workspace within Content Server (using Extended ECM) which stores the content in CS and allows access from either environment while syncing properties between them.
  • Email templates that provide a form letter email capability for inbound/outbound email associated with the case
  • Three ways of managing work:
    • Lifecycle, which is a state machine-oriented view (i.e., milestones and the actions required to move between states) for a simple case workflow
    • BPM, for a full drop to the BPMN editor for complex process flows
    • Action flow, which is a simple sequence flow
  • Mobile app creation
  • Entity relationships

There’s a lot of stuff in here, and we didn’t see it all in this short session, but looks like a pretty robust environment for low-code development. Khoyi stated explicitly that this is becoming the development for all OpenText products, replacing the workflow capabilities in Content Server and Documentum.

Leave a Reply