DSL for workflow testing

Typically a QA tests the following in a BPM Application Portal.

* Logins into Portal
* Searches for tasks based on some artifact keys.
* Saves/Completes some assigned tasks.
* Creates tasks
* Waits for some tasks.

These are the few of the many items that a tester or a Business Analyst does, not necessarily in the same order except for the first item.

Now the DSL which is to be built abstracts only high level tasks that the user performs and gives the ability to the user to write his own scenario for automated testing.

For example, if the user wants to search a task, create an artifact like Payroll and then complete the task, he would simply write as,

login_into_portal_as_user(prasanna)
tasks[] = search_for_ID(100, ‘Assigned’, ‘Available’)
iterate all tasks
if task is ‘Payroll’
create_HRA (100, current_date, hra_amount, employee_details)
complete.task
end

The above DSL code is very granular, but with further analysis and level of testing required we can build the DSL functions at coarse grained level, which would limit and simplify the number of lines a tester/user have to use to build scenarios.

One of the objectives for building custom DSL is that anybody from non developer community can write test case scenarios making use of DSL. The above mentioned syntaxes are just examples and can be made much simpler or close to readable English.

I believe this can definitely complement performance testing tools as well. The DSL testing code need not be in the above format; even as XML would do and having DSL on top of any other workflow testing tool means that the services alone will be tested for functionality.

But when I thought about DSL for testing my intention was to use it at a UI level which would better comprehend what an actual tester does. Web flow / UI Level automated testing comes with some disadvantages too, due to the fact that DSL objects are highly dependent on HTML source.

DSL’s are evolutionary and the functionality that have to be tested using DSL should be built brick by brick. Dynamic scripting languages are good candidates for building DSL, reason being faster development time opposed to using a high level language. I was looking at Ruby + ‘Watir’ (pronounced as water and is a Ruby gem) for building a DSL with automated UI level test scripts.

Who needs BPM?

BPM should be an organization wide initiative not a department specific or systems specific. This should be the real motivation for any company planning to invest in BPMS. All the business processes of the organization have to be discovered/implemented/migrated/automated to BPMS platform. This has to be the end state or at least should be an ideal state for the IT division of a company.

Workflow Systems:

Although BPM systems have its roots with Workflow systems, BPMS is definitely not an extension of a workflow system.
Workflow is no substitute for BPMS and BPM is rather looked at as systems-to-systems technology.
Also workflow is specific to a system/ collection of systems, but does not collectively represent a domain.

EAI/ESB:

With the advent of SOA, I feel the debate of whether we need to use ESB or existing EAI system becomes nullified.
SOA can be implemented either with EAI/ESB or even without these.
In my opinion BPM can be better sold with SOA rather than with ESB. ESB is perceived both as a product and as architecture. Let the customer decide whether he needs an upgrade from EAI to ESB with necessary cost justifications.

BPM complements SOA and vice versa.

BPEL vs XPDL

BPEL:

BPEL is an execution language for Business Process which it achieves via Web service interactions.

Pros:

1. BPEL is powerful since it is based on orchestration mechanism. Since there are lot of WS* specifications, BPEL is tipped to support WS* specs more effectively than XPDL, due to the fact that BPEL itself is based on Web service interactions.
2. Even though XPDL and BPEL are open standards, BPEL is embraced by more vendors, like IBM Websphere Process Server, Oracle BPA, jBPM.
3. BPEL evangelists claim that a BPEL generated by one tool can be executed in any of the process engines. I'm not sure whether this is possible always.

Cons:

1. BPEL spec is too difficult to understand and complicated.
2. The time taken to develop a BPEL process takes more time than BPMN+XPDL process.
3. Not human friendly - however BPEL4People/WS-HumanTask are intended to help BPEL.

BPMN + XPDL:

XPDL schema transforms BPMN representation to process engine executable language.

Pros:

1. BPMN is human readable. Captures, process semantics and graphical details.
2. XPDL is easily extendable. Provides more scope for BPM product vendors since, XPDL is easily extendable to provide proprietary add-ons.
3. Even though not embraced like BPEL, its immensely popular among the best selling BPM products, like Savvion, Aqua Logic, iProcess, Global 360, EMC, Adobe, Cape Vision.

Cons:

1. Vision for support on WS* specs are very poor.
2. XPDL is becoming very product dependent, since product vendors extend it by putting add-ons.

My personal opinion is both XPDL and BPEL are still immature and we have to wait and watch, which among these two become widely adopted. BPEL process getting executed on any process engine is still not a reality. Its like EJB being deployable on any App server promised by J2EE spec, but the reality is lot deviated from the stated premise.

Why BPEL Matters?