In contrast to contemporary activity-centric process-aware information systems (PAIS), for which a multitude of concepts and implementations exist, there is only a very limited number of PAIS implementations using data-centric, artifact-centric or object-aware approaches. This demo paper presents the implementation of a client-server runtime environment for the object-aware approach to process management. Our implementation is based on the PHILharmonicFlows conceptual framework, where individual processes de ne the behavior of an object and its interactions with other objects. The current implementation of the runtime environment allows for the instantiation and execution of micro processes, which de ne object behavior. Interaction with a data-driven micro process instance is enabled through automatically generated userforms as part of a graphical user interface. Additionally, the user interface can display the progression of a micro process instance using an interactive graph.
Hard-coding the multitude of forms necessary for modern business applications, as well as their respective internal logic, makes developing or changing business applications resource- and time-consuming. Furthermore, increasing competitive pressure and reduced time-to-market require companies to develop business applications at higher speeds without letting quality deteriorate.
PHILharmonicFlows is a framework for object-aware process management
that aims at reducing the development and maintenance time of forms in regard
to changes in the data model or individual business processes [
The tool presented in this demonstration allows for the execution of micro processes and demonstrates the corresponding automatic form generation. 2
PHILharmonicFlows - The Micro Process Perspective As mentioned in Section 1, PHILharmonicFlows allows for the generation of generic user forms. To this end, the framework introduces the concept of an object as a collection of atomic data types, called attributes. The attributes belonging to an object de ne all possibly displayable form elds concerning the real world entity the object represents, such as a job application. Clearly, for one real world entity, multiple forms become necessary. The forms must be shown to the various process participants at di erent points in time. A job application, for instance, must be created by an applicant, using a form. At a later point in the execution of the process, an application reviewer must be shown a di erent form, which allows him to see and rate the information that the applicant entered.
In order to support multiple forms per object, the object's attributes can be grouped into states. Simply put, a state represents one form which can be viewed by an authorized process participant, for example the aforementioned application reviewer. The attributes present in the state determine the form elds that are available for editing. Each object has an associated micro process, a ow graph which allows for the de nition of an order in which the object can reach its various states, based on data-driven decisions. The object can only be in one state at any given point in time.
For example, a \Job Application" object, which is in the \Under Review" state, shows a generated form to the application reviewer. The generated form contains a eld for the \Review Assessment" attribute. The state of the \Job Application" object changes to either \Accepted" or \Rejected", based on the value the reviewer assigns to the \Review Assessment" attribute. These state transitions, as well as the logic of one such form can be modeled in the object's micro process. In the ow graph of the micro process, each of the object's attributes is represented by a micro step. The arrangement of these micro steps within the individual states de nes the form's logic. This is achieved by interconnecting the micro steps with transitions, thereby introducing an ordering. The transitions can also be used to model conditional branching.
Returning to the previous example of the \Application" object, the \Under Review" state of the object's micro process could be modeled as follows: The rst micro step represents a string attribute \Internal Comment". The second micro step, representing another string attribute \Public Comment", is attached via a transition. Finally, the previously introduced \Review Assessment" attribute, an enumeration with the values \Good" and \Bad", is represented by the last micro step in the state. The \Review Assessment" micro step is attached to the \Public Comment" micro step with another transition, creating the micro process model visible in Figure 1. The form which is generated for the \Under Review" state shows one form eld for each of the attributes contained in the state. The elds are marked as required in the order induced by the micro process (cf. Figure 1).
Under Review Internal Comment
Public Comment
Review Assessment
As the execution is data-driven, the progress of the micro process advances to
the next step as soon as a value for the current step is entered. As the
PHILharmonicFlows Framework allows for exible execution, similar to the case handling
tool BPM|one [
The PHILharmonicFlows Runtime Demonstration Tool The PHILharmonicFlows runtime environment we present in this demonstration consists of a web service, hosting the PHILharmonicFlows runtime, as well as a client user interface, the Runtime Demonstration Tool (RDT)1. The RDT is implemented as a Windows Universal Application, allowing us to run the RDT on any device running Windows 8 or Windows 10. This means we can evaluate the feasibility of object-aware process management in various scenarios involving desktops, tablets, mobile phones, and even large tabletop computers, using a single uni ed codebase. Implementing the server as a web service will allow us to write web-based clients and native clients for other operating systems in the future. Client applications need only understand a simple WSDL containing the view model and small number of operations.
The current version of the client and server allow for the execution of micro processes (cf. Section 2). Micro processes describe the behavior of an object, i.e., which data attributes have to be provided when and which state changes to the object this entails. Figure 2 depicts the RDT in a split view showing the graph of one such micro process 1 , as well as the generated form 2 for the micro process' current state 3 . The RDT always keeps the two displays, the 1 A screencast is available at https://vimeo.com/130551330 form and the graph, in sync with the runtime server, where the actual micro process instance resides. When users of the RDT supply attribute values via the generated form or by editing micro steps directly in the graph, a web service is called, informing the runtime server of updated attribute values. The datadriven execution model of PHILharmonicFlows then evaluates the e ects that the newly supplied or changed attribute value caused and sends change set deltas to the client, allowing it to update the displayed form.
In the example in Figure 2, supplying a value for the \Urgency" attribute causes the server to inform the client, that the \Return Date" attribute has to be marked as required next. Once both \Urgency" and \Return Date" are supplied, the \Review" object changes its state from \Initialized" to \Pending", causing it to show up in the worklist of any process participant who is authorized to view the \Pending" state. The process participant can then edit the form for the \Pending" state.
The visualization of the micro process instance as a graph gives a quick overview on the progress of a micro process instance. The graph supports live updates and changes immediately when other users concurrently edit the object's attribute values, thereby advancing execution of the micro process. The color coding of the micro process' states and steps according to their runtime markings, e.g. Waiting or Activated, helps us to explain and demonstrate the more complex points of the PHILharmonicFlows concept.
Figure 3 shows one of the menu pages of the RDT, speci cally the \Objects" page. The \Objects" page gives authorized users an overview over all object types present in the current PHILharmonicFlows project. An object type is a build-time model of an object. The object type contains the de nitions of the object's attributes, micro process and authorization settings. Each object type is represented by a tile 4 in Figure 3. Every tile contains a scrollable list of all the object instances 5 that exist of the object type. The list also shows some metadata determined by the current state of the object instance's micro process. Selecting an object type shows various meta information and allows users to create more instances of the object type. Selecting an already existing instance on the other hand allows users to edit the form generated for the instance's current state and view the live graph depicting the execution of the micro process instance (cf. Figure 2). 4
Conclusion The demonstration presents parts of the PHILharmonicFlows runtime environment, consisting of a web service hosting the process server and a graphical user interface. Together, they allow for the execution of PHILharmonicFlows micro processes. The user interface enables interaction with running process instances via generated user forms, worklists, and graph models. While the current version only supports micro processes, we are working on adding support for macro processes, which enable interaction between multiple objects' micro processes, allowing for far more complex processes to be executed.