Language Improvements
I this chapter we will discuss some proposals on new language features, which would make writing workflows easier.
Variable mapping with OCL query
Currently, only a whole Variable can be mapped to parameter of Activity. But what if one wants to map property of such Variable? Well, such desire can be worked around by defining Executable that takes Variable as input parameter and outputs the property. Resulting workflow contains one Executable and one Variable more than it would have to if mappings could use OCL query as a source.
Expected Functionality
OCL input mapping should define OCL query as a source. The query would be evaluated just like OCL condition on Transitions. Result would be mapped to given parameter.
OCL output mapping should define OCL query as a source. The query would be evaluated just like OCL condition on Transitions only the environment would contain output parameters instead of process Variables. Result would be mapped to given Variable.
Implementation
Workflow language definition would have to be extended. Engine implementation can reuse OCL evaluation code from Automaton. IDE implementation can reuse code for editing of Transition condition.
Output parameter of previous Activity
Currently, output parameter of previous Activity must be mapped to Variable to be usable. But what if one wants to use it only in immediate Transition condition or as input to next Activity? Workflow then must define extra Variables just for that purpose. Such occurrences are quite common, for example when user chooses next action, identifier of the action is often used only to select Transition.
Expected Functionality
OCL evaluation environments should contain values of output parameters of previous activity. Parameter names should be prefixed to avoid collisions. Mapping can access the feature via extension described in programmers documentation Section 1.1.
Implementation
In the engine, Automaton would have to store values of output parameters so OCL evaluation has access to them. Since Automaton doesn't execute Activities, it would have to expose setter for Basic Process. IDE would have to retrieve output parameters of previous activity when examining OCL conditions and queries.
Web Platform Runtime
Recently, Web Skills, a realization of Skills form on the web platform, was developed. UIWFEn Project will be probably extended to work on the web platform too.
Expected Functionality
From the user perspective, web platform runtime could look and behave like RCP Platform Runtime. Specifically, user could navigate workflow via Web Viewer integrated in a web page. The web page, including Web Viewer, is expected to interact with data on the server. User interface can be similar in functionality to RCP Viewer. It should feature the next and the previous button. Web Viewer probably won't allow user to select workflow to run. Such job can be left to the web page if needed. Web Viewer is expected to be component rather than stand-alone application.
Challenges
Implementing runtime on the web platform seems challenging. For instance, at the moment, the implementation of web Skills is rather bleeding than cutting edge of Skills technology. Implementing of required client-server architecture can be challenging too, especially when communication channels on the web platform are limited. Some aspects are potentially web server specific, so multiple realizations might be required.
Expected Architecture
Web Viewer can be split into server and client part. Client part should be a component of web page displaying user interface. Client user interface can then trigger events on the web server via AJAX. Events triggered on the web server should be propagated to the server part of Web Viewer. Server part of Web Viewer should manage a Web Process, which should be a realization of Form Process on the web platform.
AJAX
AJAX is an acronym for asynchronous JavaScript and XML. With Ajax, web applications can send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display and behavior of the existing page. Such technology is essential to provide communication channel between client and server part of Web Viewer.
Web Process
As has been said, Web Process should be a realization of Form Process on the web platform. It should be a subclass of Form Process and implement platform specific functionality. Question is, what exactly belongs to this platform specific functionality. Let us review each Activity type, to find out what is different.
Subprocess
Subprocess is buried deep enough in abstraction to remain unaffected by platform.
Executable
The code of Executable can affect only server side. If it is to affect client side, it needs a communication channel. There are many ways to do so and perhaps it is best to leave it outside of scope of web runtime.
Custom Form
The question is how to provide Custom Form a way to build client user interface, when it executes on the server side. One solution is to provide extension of IJavaTaskEnvironment. The extension could feature method accepting web page source code representing the Custom Form, the source code can be then sent to client via AJAX. Another problem is with retrieving user input. This could be solved by callbacks implemented via AJAX. Provided extension of IJavaTaskEnvironment would simply allow Custom Form to register for these callbacks. Code of Custom Form can also influence client user interface, it can disable/enable the next button, or trigger advance to previous or next activity. Again, these features can be implemented using AJAX.
Skills Form
Abstract Form Process methods have to be implemented using Web Skills framework. Additionally, availability of the next button has to be updated depending on validity of EObject displayed in the form, these updates can be sent via AJAX.
Server part of Web Viewer
When the server part is created, it should receive configuration data and initialize Web Process and pass input data to it. This includes opening data sources. If Web Process successfully finishes, data sources have to be updated.
Another job that might fall upon the server part is to provide connection between AJAX and Web Process. AJAX event usually triggers some script on the web server and this script then can interact with the server part. This interaction might depend on capabilities of used web server, so several implementation of the server part of Web Viewer might be needed.
Client part of Web Viewer
Client part should be a component of web page, so it can be included in complex web page.
It should show current activity and buttons for advancing to next and to previous activity. The buttons should be implemented via AJAX, because if they load a different web page, it can render browser history unusable.
Workflow IDE
Future tasks on Workflow IDE aims on simplifying workflow design process for user even more. For example we would like to make Variables mapping easier with some graphical tool, maybe using Graphiti for this.
Next task is Graphiti related too. Because of its early development state, we expect changes and major improvements in coming versions and we will have to adapt editor to them.