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.
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
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
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
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.
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.
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.
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.
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.
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 is buried deep enough in abstraction to remain unaffected by platform.
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.
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.
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.
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.