Technical Workflows

1. Classification of Workflows

People + Systems

This application case shows how technical sub processes are integrated directly (above) or via subsystems (below) into human-centric form-based processes.

Technical workflow management is not only about people but also systems, so that essentially different software systems can be integrated. Strictly technical workflows without any human interaction are rare, so that the features described here must always be seen in the context of a human workflow.

Departmental Integration

This is a schematic representation of a scheduling workflow at a television station (CEITON in blue). Instead of crisscrossing all systems (orange) to connect to each other and letting human communication in from outside, the technical and human communication is coordinated by a central workflow (backbone). Creative departments (left) work in a structured and lean way with production (right) and management (below) - and even with external customers or suppliers (far right).

This also differentiates a workflow system from an automation system, which only integrates specialized external systems, such as machines, low-level or proprietary systems or file formats. Therefore, these are integrated as needed as automations or sub-automations into an overall workflow. A workflow then takes care of the exchange of data between people, the automation solutions and the higher-level software systems such as billing systems, customer and order management, archive systems and so on. Thus, the economic (financial) level and the technical (executive) level are linked and no longer exist in isolation.

Centralization

Through centralized systems, otherwise sprawling interfaces (left) can be reduced to the minimum (right) and maintenance centralized. Nevertheless, each system can still communicate with each other. If no dedicated EAI system is available, this can also be taken over by the workflow system.

Since the workflow system therefore tends to have to incorporate very many very different systems, there is no fixed inflexible API, but rather functions from the world of EAI. With these functions, the previously distributed interface logic is (1) centralized and (2) more flexible and (3) the number of interfaces is drastically reduced. You no longer need to program and maintain interfaces from each system to every other one, but the interfaces can be designed without any programming in a central EAI layer. This is done by mapping the metadata between the target and source system, so a system can be connected once and communicate over a different mapping with all other systems. In this way, the workflow system can even elegantly integrate systems or an external EAI system, which explicitly performs these and other tasks.

Adapters

An adapter to an external system (shown in gray) is defined, based on protocol plug-ins (e.g. webservices), as several interface definitions (red) for an array of calls. These definitions to arbitrary systems are defined entirely without programming and can be changed within seconds and at any time. Thereafter they will be hooked into workflows (blue) and are processed at run-time based on the workflow dependencies.

The integration of the systems works in the EAI layer via adapters or connectors that speak the 'language' or the protocol of the system to be integrated, i.e. as XML, RMI, COM, SQL et cetera. The most modern is the SOA approach, in which web services (XML files wrapped into the web) are used as connectors. Due to the web's wide availability and the self-descriptive XML files, the functionality (services) of the various systems can be used and re-used more easily. Therefore, the workflow system supports and enables the SOA approach, in which its own workflow services are made available and other web services are integrated easily by EAI capabilities.

The CEITON workflow system therefore has as standard the central automation and EAI/SOA capabilities in order to integrate external systems into the workflow. If, as already indicated, additional functions are necessary, external infrastructure systems (e.g. SAP, Oracle, etc.) can be connected even more easily, because then two flexible EAI/SOA systems talk to each other. The workflow system coordinates flow of tasks and information (metadata), leaving the technical connection of external systems to the external infrastructure solution (EAI e.g. by SOA). This is not itself a workflow management capability, but only the technical basis for the exchange of data to other systems which can be used by the workflow system to integration. This is mostly the case for our larger customers.

2. EAI and SOA on the Back-End

When systems in the background, on the server side for example, are connected to each other, we speak of back-end integration. Examples are an export into an ERP system or a call of a server service.

Using the CEITON EAI module of the workflow system a wide variety of interfaces can be freely defined and adapted without programming. Typically interfaces are designed for the following types of systems:

DAM Integration

In the sub-form of a WOF (Work Order Form) modeled in this way, content is selected (left/bottom), which is queried live from an arbitrary Media Asset Management System (from the search on top). The selection then creates dynamic areas in the underlying WOF, in which the metadata of the selection is displayed and can be edited if necessary. This and additional (invisible, if so required) data are then available for further processing e.g. by the subsequent workflow.

In this way, very different standards and interface versions can easily be implemented without any programming, such as:

or any other future emerging definition, such as ones defined by AMWA.

Data Collection

In forms for people, information is gathered and then forwarded to a technical system for execution and automation.

These interfaces differ in various ways, such as:

Furthermore, the interface definitions to be defined differ according to the protocol:

The EAI capabilities enable the following benefits:

As far as the workflow system is concerned external systems are black boxes with which it exchanges information, as well as exchanging information with people using forms. The workflow engine uses the form server in one case and in the other the EAI module. What is happening in detail is completely irrelevant for the workflow system. It merely processes information using pre-defined rules and relationships so it can also be applied to arbitrary processes and industries.

3. EAI on the Front-End

GUI Integration

As an example of a preview integration of videos, YouTube was integrated here as a media asset management system (MAM) into a work order form (WOF). In this, content in the MAM can be searched for, viewed and selected, and can then be taken into the WOF along with metadata. The data can be viewed and, if required, edited in a WOF (right hand side with two content items). The interface here was defined based on HTTP REST calls.

When the user interfaces on a client machine are connected to each other, we talk of front-end integration. This is for example the case when part of a program is to be mashed up into another, or one is called from another.

This is somewhat useful if an employee receives a task in the workflow system and then has to complete this task in another system with part of the data, such as an order in the ERP system or a search in the archives. With the CTWS EAI system, the external application can be opened with one click, so that the appropriate screen is immediately filled out with the right data. Then a subject-specific task can be performed in the external application. After completion of the task, all the information is available to the workflow system for further handling in the process.

SAP Integration

From a web workflow (background), the SAP GUI for Windows (foreground) is started in a specific transaction (an operation) is started and populated with data from the workflow, so that integrated work across systems is available to the user. Because of SSO (single sign-on), another logon is not required. On ending the tasks in the external system, the workflow system has already received the data and can continue processing it.

The front-end integration is easier with Web-based systems, but also goes well with locally installed programs or complex client/server systems (C/S) such as SAP GUI for Windows.

In general, the EAI front-end module distinguishes between the following types:

SSO allows secure calling of all interfaces to third-party applications without re-authentication, so that the workflow is fast and comfortable for the user. Different LDAP servers, Active Directory, SAP, etc. can be used.

The front-end integration is often composed of a set of integrated interfaces, which can be easily defined via the EAI module, thereby hiding the actual complexity.

Because normal EAI systems do not show a GUI to the end-users, these features are also available only in the CEITON system.

4. Monitoring and Recording

If processes are to be controlled, one usually also wants to monitor them, to intervene based on status, etc. and if required, to reschedule. In the workflow system, we perform process monitoring of machines and systems (machine data acquisition), but no system monitoring via SNMP (operating data logging).

Since all data and interfaces in a workflow are individually modeled through an application process, the monitoring screens and sub-workflows for escalation are independently model-able. All the options of messaging, graphic interfaces, lists, external logging, and so on are available.