Einheitliche und pragmatische Konzepte

Die Smart Business Context Services (kurz: sbcs oder smart-bcs) implementieren generische Anforderungen einer Daten- und Dokumentenintegration über verschiedene Anwendungen hinweg in unerschiedlichen, konfigurierbaren Services, die alle die gleichen Konzepte und Technolgien unterstützen:

• Alle Komponenten sind über eine public REST-API erreichbar (JSON als Datenformat)
• Die Komponenten verfügen über eine interne JavaScript-API und implementieren Hooks, über die geschäfts- oder kundenspezische Logik implementiert und zur Laufzeit geändert werden kann.
• Konfiguration statt Programmierung: Wo immer mögliche, reduziert sbcs die Notwendigkeit für Programmierung und präferiert statt dessen Konventionen
• Erweiterbarkeit über Adapter

Überblick der Komponenten

Master Data Hub

Der Master Data Hub (MDH) agiert wie eine grosses vituelle, relationales Datenbank-Schnittstelle auf all Ihre Unternehmensdaten und verbirgt dabei die verschiedenen Systeme, APIs und Technolgien. Die Daten werden über konfigurierbare "Entitäten" logische strukturiert. Die Entitäten definieren ihre wichtigen Geschäftskontextobjekte wie Geschäftspartner, Vorgang, Bestellung, Produkt, Vertrag. Jede Entität hat seine konfigurierbaren Attribute, die mit den Atrributen des entsprechenden Backends über eine Oberfläche verbunden werden. Entitäten können Relationen zu anderen Entitäten haben, auch wenn diese in ganz anderen Systemen verwaltet werden. Der MDH verwendet Technology- oder Anwendungs-Konnektoren, um auf die verschiedenen Systeme zuzugreifen. Die Konnektoren stellen CRUD-Methoden (Create, Read, Update, Delete) bereit und übersetzen die spezifischen APIs und Datenstrukturen der Backend-Systeme zu einer einheitlichen Schnittstelle, auf die über eine offene REST-API gegegriffen wird.

Im Gegensatz zu einem Enterprise Service Bus (ESB) ist der MDH auf synchronen Datenzugriff fokusiert, erreichbar gemacht über eine strukturierte REST-API. Der MDH kann zur Laufzeit über die Admin-Oberfläche oder per REST-API (um-)konfiguriert werden. Es gibt keine Notwendigkeit für Deployments und Downtimes, um neue Entitäten anzulegen oder existierende zu ändern. Der MDH persistiert nur die Entitätsdefinitionen und das Mapping der Atribute (das Know-how für den Zugriff auf die Backenddaten), kann aber für eine bessere Skalierung Daten cachen.

Der MDH stellt bereits folgende Referenz-Adpapter für den Zugriff auf Backend-Systeme zur Verfügung:

• 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 a 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 in 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