-In any organization, the use of default web applica- In [2] we have proposed generic (process-independent) tions that come with their software infrastructure, e.g., a Business BPMS user portal which can be integrated (loosely couProcess Management Systems (BPMS), is the best option in pled) with potentially any process engine for the execution Hmoawnyevcears,etsh,eirfethareey sfoumlfiellctahseesreinquwirheimche nittswoofuslducbhe odregsairnaizbaletiofonr. of business processes. It is based on a unified data model an organization to be able to develop or to integrate their own and a generic process engine API. We have modeled our user web portal with the legacy infrastructure. In previous work generic BPMS user portal using WebML [3], a domainwe have proposed a generic BPMS user portal which can be specific language for web applications. WebML can be seen integrated with potentially any process engine for the execution as an extension of the Interaction Flow Modeling Language opfrobvuidseinaenss epxproecreiesnsecse. rTephoertmoaninthoebujescetiovfe thoef Itnhtiserapcatpioenr Fislotwo (IFML [4]), a standard language designed for expressing the Modeling Language and the Model-Driven-Engineering approach content, user interaction and control behavior of the frontfor the generation of such BPMS portal. In particular, we discuss end. A platform-independent front-end model gives us the the potential of plain IFML (i.e., the standard definition without possibility to follow the Model-Driven Engineering (MDE [5]) platform-specific extensions) for the specification of a front-end, paradigm for the definition of a Model to Text (M2T) transforagsenwerealltioans osof mthee oBpPeMnSisspuoerstableihninadtairtsgeutspelaftofrortmh.e automatic mation for generating the portal using different technologies. In such work we faced some difficulties. We specify
(a) Process area
(b) Task area
the generic BPMS portal we proposed in [
There are several proposals for the front-end development to describe the main aspects of an application front-end,
based on the MDE approach, most of them are web en- basically: the view part of the application together with the
gineering approaches as WebML [
As far as we know, there is not so much works on the defini- container is shown at a time. Also, containers can be set
tion of a generic BPMS portal. In [
View components and navigation flows are connected with a domain model which expresses the domain elements and behaviors for which the IFML model is defined.
WebML [
At the Presentation Layer level, the BPMS user web portal
provides the user with the set of functionalities needed to
manage BPs and activities cases, worklists, groups and roles,
among others. Also, other existing applications can be defined
and connected to the generic API in order to interact with the
selected process engine. The Access Layer is composed of two
sub-layers: the Service Layer where the generic process engine
API is defined exposing functionalities to the user portal, and
the Integration Layer which provides the means to actually
implement the interaction with the selected process engine.
Interoperability is achieved based on a unified data model
which was defined as an abstraction of concepts from different
process engines [
The generic API provides general services such as logging facilities, and specific services such as listing pending tasks for a given user. The Integration Layer is responsible for providing the functionalities exposed by the generic process engine API by invoking the specific methods from the selected process engine, since each process engine has different operation signatures and ways of exposing the same functionality. It comprises two main components: (i) the interface IEngineAdapter component which defines the functionalities that have to be provided, and (ii) the specific adapter component which have to be implemented for each selected process engine.
Adapters provide the functionalities defined in the interface by invoking the selected process engine, translating the response to the one expected by the generic API. This layer decouples the definition of functionalities of the portal from the implementation of these functionalities, which can be provided by any process engine via the Integration Layer. Functionalities not provided by the selected process engine can be disabled in the user portal. In this way, our BPMS generic portal does not provides yet another process engine implementation, but a clean integration with existing ones.
The Presentation Layer was formerly expressed using WebML and manually implemented using HTML5 and Javascript, as well as other frameworks for structuring code (AngularJS6) and style sheets and layout definitions (Bootstrap7). We have also implemented a concrete instance of our unified process engine API as a HTTP REST API using Jersey8, and an adapter for the Activiti process engine. The data model was implemented using the JavaScript Object Notation (JSON9) as a lightweight data-interchange format.
IFML editor. In what follows we present an excerpt of the
models, complete enough for exemplifying the use of the main
IFML elements depicted in Figure 2, and for defining the M2T
transformation in the next section. A more complete definition
of the original WebML models can be found in [
The generic BPM portal begins with the definition of a home view which contains a login form which can be used by users to access the site, as shown in Figure 5. The "Login" action has a specific dynamic behavior which allows to use the generic API to login a user to the BPMS. Within IFML actions are defined in an abstract way. However, when the generator detects such behavior, it generates the corresponding logic for login. In general, since we are expressing a presentation layer on a specific and fixed domain (not depending on the specific business process that will be executed), actions are fixed and defined in terms of our generic API.
6AngularJS. https://angularjs.org/ 7Bootstrap. http://getbootstrap.com/ 8Jersey. https://jersey.java.net/ 9JSON. http://www.json.org/
view which provides the functionalities for users of the BPMS, e.g., list of assigned tasks, perform a task, among others. It is divided into three main areas: tasks, cases and processes, which allow identified users to manage their work within the processes in which they are involved, as was exemplified for Activiti BPMS in Figure 1. The most important functionality of a web portal for regular users is the work list, in which users can list, take, reassign and complete tasks assigned to their roles (or specifically to them).
In Figure 6 we present the IFML modeling of the processes area, which allows to search for a specific process (represented with a Form component), shows a list of processes (represented as a List component) with their corresponding id, name and version, and allows to initiate an instance of any of them (represented with a navigation flow from the process list to the process form, together with a data binding for identifying the corresponding process instance). Once again, we express a "Start" action in an abstract way, but it has a specific dynamic behavior for starting the process using our generic API.
Server Faces (JSF10) which allows us to generate a front
10Java Server Faces.
http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html
end following the Model View Controller (MVC) pattern. We
selected this technology because based on MVC it provides a
clear separation between the view (pages) of the presentation
and its logic. The business logic of our application is assumed
to be provided by the generic API, which can be accessed
through web services as in [
Windows (View Container) are translated into web pages. For each window we generate two files: one with the view (XHTML page) and another with the controller (Java code). Since within a window there could be other components, their generated code is included within the same two files. When the XOR property of a window is checked (a disjoint visualization of views), we generate a lateral bar from which each of the XOR views can be selected. Moreover, if the modal property is checked, we generate a pop-up (modal) page. Finally, if the landmark property is checked, meaning that the container must be accessible from any other page, we add a link to this page in a menu bar located in the JSF application header. Form is a view component inside a view container, e.g., a window. For each form we generate a HTML form with their corresponding fields (i.e., SimpleField in the IFML specification). Each field is bound to a domain element attribute within the domain model, thus we generate the code for binding form fields to Java beans.
Action we use specific actions that are mapped to specific services within our generic API through the dynamic behavior property of the action. In this way, we generate the code for service consumption when for example a button is pressed. We also bind input and output data of the action to the corresponding input and output parameters of the service, respectively. Input and output data is represented with the datatypes generated from the domain model. Since the action has a navigation flow from it to another window, we also generate the automatic flow to the corresponding page (potentially the same). List and Details are translated into their corresponding JSF components (a list or a table). As in the case of the form, each of their simple fields are bind to some domain concept attribute.
Navigation flows are basically translated into buttons. In the case of a navigation flow from a window, we generate a button in the top right part of the page. In some cases, e.g., when navigating from a list to an action or window, we interpret the navigation flow as a repetitive action, thus we generate a button for each list element. Authentication there are some aspects of the application which cannot be expressed in plain IFML, as for example authentication controls in each page. Thus, our transformation generates a code fragment for validation which is included within each page and connected with the authentication service of our generic API.
From the technical perspective, the M2T transformation from IFML to JSF is implemented using Acceleo, an implementation of the MOF Model to Text Language (MTL) standard within the Eclipse environment. As depicted in Figure 7, the generation process takes as input a set of files produced by the Eclipse-based IFML editor representing the IFML metamodel and a specific model, and provides as output a JSF front-end composed by XHTML pages and Java components.
An example transformation rule is depicted in Figure 8. The rule queries the navigation flows defined within a window and, for each one of them, defines a navigation button to its corresponding target flow element (in this case: a window that will be transformed into a web page). We used Bootstrap components and style sheets for adding responsive behavior.
After the M2T is performed, a web project is automatically generated with the web pages and resources for executing the generic BPM portal. By setting defined configuration files we can indicate the concrete BPMS process engine that will be used, since the generated beans invoke the operations defined in the generic API. We encapsulated the invocations in a set of utility classes that are used throughout the site beans, to obtain data from the process engine. [comment Links to other pages in the upper right corner /] [if (element.oclAsType(IFMLWindow).eContents(NavigationFlow)->size()>0)] <h:form class="row"> <div class="pull-right btn-group" role="group" aria-label="..."> [for (element2 : InteractionFlowModelElement | element.eContents())] [if (element2.oclIsTypeOf(NavigationFlow))] [if (element2.oclAsType(NavigationFlow).targetFlowElement.oclIsTypeOf(IFMLWindow))] <h:commandButton class="btn btn-default" value="..." action=""/> [/if] [/if] [/for] </div> </h:form> [/if]
model in Figure 6, is the one depicted in Figure 9. The processes area is a landmark page which can be accessed from the menu bar. There is a logout button in the top right part of the page representing a navigation flow between the processes window to the logout window (not shown in the IFML models). The search form allows updating the list of processes once the button is pressed. Within the processes list there is a repetitive action for starting a process, represented as a button on the left side of each element.
our experience and describe many open research problems.
IFML has a great potential and WebRatio is a powerful tool for supporting the whole life cycle of IFML based applications. Unfortunately it is the only one, and from a research perspective it has many drawbacks: it is not open source, their metamodels are not available, and there is no information about how the M2T transformations are defined.
One of the open issues (resolved somehow by WebRatio) is the connection between IFML and other front-end aspects as graphics, styles, position and rendering of components. In our experience, the main problem when using plain IFML or one of their extensions for code generation is that many implicit decisions have to be taken, or postponed for a future step, e.g. adding styles in the resulting web application. However, it could be beneficial to have these aspects modeled and connected to the IFML model, but not as an extension of it (e.g. as a complementary model). In fact, the extension mechanism provided for IFML has some drawbacks from our point of view, as we will discuss next.
Plain IFML, i.e. the standard definition without any
extension, is enough for expressing many things, but as mentioned,
it is also restrictive. There is a need for lowering the
abstraction level in order to express platform-specific aspects,
such as: first, the technology to be used, and second, the
kind of environment in which the front-end will be executed.
With respect to the second one, IFML extensions add concrete
actions and components for expressing mobile or web aspects,
independent of any given technology. However, once a model
is built for a given environment, it must be rebuilt for another,
e.g. the use of specific view components, although many of the
aspects already expressed do not change, e.g. the navigation
between containers. In some approaches, e.g. UWE [
Based on the existent IFML extension mechanisms, it is
possible to come up with an IFML extension for modeling
BP execution, in connection with the generic process engine
API defined in [
With respect to the definition of M2T transformations, Acceleo is a very powerful tool but his template-based approach can be tricky if there is no previous intention of reuse (e.g. lack of explicit modularization). In particular, it is desirable to define a library for querying the source model, i.e. in the case of IFML, for retrieving every container, every navigation flow from a given component, and so on, which can be reused no matter the target of the transformation. If not, templates result in a mixed combination of explicit model queries and generated text which is hard to read and does not allows reuse.
Finally, from a component perspective, the BPMS world provides an example of componentization in which process engine functionalities can be abstracted and the user interface can be reused in new contexts. The generic API is the most valuable component within the architecture in Figure 3. In order to enable different BPMS providers we can follow an ontology-based approach for mapping their engine services against a set of ontologies in order to support the discovery and invocation of services. This is intended as future work.
In this paper we presented an experience report on the use of IFML and the MDE approach for the generation of a generic BPMS user portal which can be integrated (loosely coupled) with potentially any process engine for the execution of business processes. We provided a plain IFML specification of such a portal and a the definition of an Acceleo M2T transformation for the generation of a JSF-based front-end.
We found that plain IFML has great potential for the generation of a front-end, but there are many issues that must be resolved for improving such front-end. In this sense, we discusses several open problems related with the inclusion of complementary metamodels (e.g. for styles) and the use of a multi-modeling approach for expressing different abstraction levels. We also discuss the possibility of defining an IFML extension for modeling BP execution in an abstract way.
tation, it brings UI experts closer to non-technical stakeholders. However, it is possible to go one step further considering a mockup-driven approach in which IFML can be considered an intermediate model for representing certain aspects of a frontend. In this approach, model-to-model transformations could be defined from some mockup language to IFML and other languages in the multi-modeling approach we discussed.
project regarding the prototype implementation: Adrian Dos