Forms & Workflow Service

Projekt Firma Document Resource Master Date Hub Task Client Typ:  Korrespondenz Partner: Müller AG Projekt:  P-0137 Klassifizierung Ablage Validierung Forms & Workflow

Support and control your business processes by one open and configurable layer of services for documents, tasks and business object data which are stored in different systems and technologies. Open your data silos and make them accessible from one generic layer structured and connected following your business process instead of your backend systems. Integrate relevant context data in any Java Script and HTTP capable framework or application using one global REST-API.

How to make this happen?

The Smart Business Context Services (sbcs or smart-bcs) separate the generic requirements in different configurable services supporting the following concepts and technologies:

  • All components are accessable from a public REST-API (JSON as data payload)
  • Most components have an internal JavaScript-API and hooks to support business or customer specific logic to be changed and implemented during runtime
  • Configuration instead of coding: where ever possible sbcs reduces the need for coding and prefers conventions
  • Extensibility by adapters

Master Data Hub

The Master Data Hub (MDH) acts like one virtual, relational database interface for all your enterprise data - hiding your different systems, APIs and technologies. The data is structured in configurable "Entities" defining your important business context objects like business partner, case, order, product, contract. Every entity has it's configurable properties mapped to backend properties and may have relations to other entities independent from their backend. The MDH entities use pluggable technology or application connectors to access the different systems and to provide generic CRUD (create, read, update, delete) methods. The adapters translate the specific APIs and data structures from different backends to one interface to be accessed from one open REST-API.

In contrast to an Enterprise Service Bus (ESB) the MDH is focused on synchronous data access exposed on a structured REST-API. The MDH can be (re-)configured during runtime using the admin user interface or the REST-API. There is no need for deployments and downtimes just to define new or change existing entities exposed in your enterprise. The MDH persists only the entity definitions and the backend mappings (the how to access the backend data) and may cache backend responses for better scalability.

The MDH provides already the following reference adapters to connect backend systems:

  • MySQL (JDNC)
  • Postgres (JDBC)
  • Redmine (REST)
  • EspoCRM (REST)
  • Alfresco ECM (CMIS)

Depending on the backend API, data structure and the expected functionality it is quite easy and straight forward to implement new adapters for other systems by implementing the MDH Java adapter interface. Please contact us if you have a specific backend and use case in mind to get an estimation and/or our support.

Forms and Workflow Service (FaW)

The forms and workflow service has the proven concepts of paper forms in mind used in the old school processes but translated and adopted for the new technologies and cloud platform concepts. It combines a flexible and dynamic task and forms service with the other smart-bcs services like master data, document resources, flows and the status machine. Faw deliberately does not use the concepts seen in most BPM and Workflow engines which expect to define (and code) the whole process in more or less one workflow definition which can't be modified once a process instance is running. Instead we follow a simple task model which can be combined with dynamic forms and actions. A task has a flexible set of metadata and an easy to configure form for user interaction and an task instance is assigned to a group/role, a person or a backend process. A task is notified by push (amqp) messages and may support different clients and platforms in parallel. The Forms and Workflow Service provides a task client application for power users to be installed as an tray app (Windows, MacOS, Linux) which will receive push notifications and handle dynamic task forms very similar to an email client. A Task form is declared as JSON (json form) on a JSON Schema and is beeing rendered as a flexible HTML form supporting different UI controls and validations. Tasks and forms have a server side JavaScript-API which listens on user interaction and allows to modify and validate task and form instances on the fly. All data entered is persisted in the json schema of the form and accessable by API and a form history journal. Users may access and view the form for any change from the task journal.

A task may have registered several configurable actions for pre and post processing. This includes initializing new tasks and forms based on context data, analyzing and converting attached document references (leveraging the resource service), validating entered/modified data and creating and assigning follow tasks and actions.

Work in progress: Upcoming releases will support a flexible status machine service which implements a configurable role based status lifecycle mechanism respecting global defined business rules. A status can be seen as a flexible value list which behaves different depending on the active value, context data and user or role accessing the list to change the active value. For example a status for a document to be checked could be switched from "in review" to "reviewed" by the assigned reviewer but the manager role may switch also to "canceled" or "approved". This mechanism would avoid most of the coding required by other workflow engines.

Resource Service

The Resource Service is very similar to the Master Data Service but specific for hiding systems storing documents. This service is necessary to implement generic workflows having not only data but also documents accessible from the context without the knowledge where these documents are stored. A resource is created by either uploading a document or by providing a reference to an external document store supported by a resource service connector. A resource can be accessed by a token (cryptic unique string) and supports some (document type specific) embedded methods to:

  • get document metadata
  • transform the given document to other renditions like preview, pdf, html (if required transformers are registered)
  • transfer document to another backend document store (still keeping the token)

Out of the box the Resource Service supports:

  • file servers
  • Alfresco ECM

Depending on the consuming client system and the use case the access token for a document token is not even exposed the the frontend applicaton wich enables a new access policy: a user requires access to a service context like a specific task to get access to a document resource.

Ticket Server

Architecture

Technologies:
    Master Data Hub, Forms and Workflow, Resource Service, Status Machine
    Java / Dropwizard
        REST-API
    Ticket Server, Task Client
    Pyhton/PyQt