BPMATEOAS?

[klimperos]

Hello,

HATEOAS seems to have picked up steam, especially now with the endorsement of the good people at VMWare aka Spring: http://www.springsource.org/spring-data/rest , the new Spring HATEOAS project, and now ROCA (http://roca-style.org/index.html) which has some interesting assertions about how to use hypermedia to drive front-end state transitions.

Having implemented a few workflow processes with Activiti, to-date, the above has left my wondering how Activiti fits in to the fully-RESTful universe. Would HATEOAS front-ends have a side-effect of driving an Activiti process through its REST interface? How then would RESTful "resource state" relate to Activiti process state? Is this a case of "well, you can do it, but good luck to the developer"? If so, does some kind of tighter integration between Activiti and a HATEOAS app that might come out of, for instance, Spring MVC and Spring HATEOAS make sense?

Also, in the parallel universe of Single Page Apps, dozens of .js libs, Node.js, and noSQL, does RESTful integration with Activiti make sense or do such apps tend to satisfy a less sophisticated problem space?

Thank you.

[trademak]

Hi,

What we want to offer with our Activiti REST module is easy remote access to the Activiti Engine.
The style the REST interface is implemented in can differ depending on what's hot and what's you personal taste.
Right now we try to keep the REST module simple with a list of services that you can invoke.
I don't see any direct benefit of having a HATEOAS implementation, do you see some?

Sure, the exploding number of .js frameworks make sense for Activiti, as this can satisfy specific UI needs.
NoSQL and Node.js are two other beasts I think.

Best regards,

[klimperos]

Hi Tijs,

Yes, I do see a direct benefit of a HATEOAS implementation.

I've found accessing the REST module straightforward by following your book's pattern of extending the RESTlet code for new web services. But, a curious issue cropped up when I created a demo mobile web application that interacted with an Activiti process. There was a required bifurcation of web services between those using the Activiti API and driving Activiti process and data-oriented services also required by the UI. And my implementation became a mixture of RESTful-CRUD and Activiti REST.

This approach troubled me because it meant two different, yet equally important paradigms were required and certain race conditions between them could occur. While I handled both of these, it didn't seem idiomatic nor ideal. Since BPM serves mainly workflows involving people, the UI can be tightly woven into business processes. In fact, the Vaadin-driven default UI that comes with Activiti, while not HATEOAS-compliant, is nonetheless tightly woven with the UI because the Activiti Explorer UI tasks are tightly coupled to particular Activiti process states.

I propose that if we instead think of HATEOAS as implementing an Inversion-of-Control pattern for the UI, we could attain, with Activiti, a favorable conflation of UI process state and business process state. For example, what if you could create a new UI-process, where the design palette is enhanced with objects relevant to the UI domain? You could then use the process engine to drive client UI state and provide idiomatic hooks to associated business processes.

In my mobile web demo, each time a user created a new request, a REST service created a new Activiti process. But the UI state was managed in the mobile web app itself and I designed the REST interface as described above to make the whole app work. If I could have instead created a new "Activiti UI process" that drove the app itself, and was given hypermedia links that, when followed, resulted in state transitions of both the UI and underlying business processes together, then I could decouple the UI and business processes and drive them independently with the same process engine.

My opinion is that Activiti is a natural fit with HATEOAS, since it already handles process flow well. It could be made the cream of a new crop of fully REST-compliant HATEOAS/BPM workflow engines.

[trademak]

Hi,

Thanks for your response. It's still not very clear to my what your pointing at. Could you give a more technical response with example REST services to make it better understandable?

Best regards,

[klimperos]

Tijs,

I'll use a slightly modified loan process example. The idea is that the UI state is not necessarily captured by the Activiti business process, rather by whatever state machine is in the UI controller. Some UI controller states trigger inputs to the business process. Here's an example based loosely on the canonical loan approval process:

Actor: Loan Shark (LS) Agent
The LS agent will collect data from the customer and input it into the system, after running a preliminary credit check, to save time for the Approval agent in case of spurious loan requests.

http://erbium.3phasecomputing.com:8080/activiti/fig-1.jpg

Figure 1: UI Process, Credit Review and Loan Application Entry

Suppose we want to create a web app that supports the UI process above. Here's one possible implementation of REST services that could work, using a basic HATEOAS/atom interaction:

Start: Loan Agent logs in.

Request: GET /service/loan-agent-options
Response:
{
   "View-info" : [ {
      "options" : [ { "1":"New Loan Application" , "2":"Review Loan Application" } ],

        "description" : "Loan Agent Options",
      "links" : [ {
        "rel" : "self",
        "href" : "http://serverHost/loanAgentOptions" } ] }
   ]},
   "links" : [{
       "rel" : "creditReport.input",
       "href" : "http://serverHost/service/creditReportRequest"
     },
     {
       "rel"  : "loan.review",
       "href" : "http://serverHost/service/loanReviewRequest"
   }]
}

Request: GET /service/creditReportApp
Response:
{
   "View-info" : [ {
      "description" : "Credit Report Request Data",
      "details" : [ { "1" : "Name", "2" : "SSN"],
      "links" : [ {
        "rel" : "self",
        "href" : "http://serverHost/service/creditReportApp" } ] }
   ]},
   "links" : [{
     "rel" : "creditReportRequest#post"
     "link" : "http://serverHost/service/creditReportRequest"
   }]
}

Request: POST /service/creditReportRequest
Response:
{
   "links" : [{
     "rel" : "creditReport"
     "link" : "http://serverHost/service/creditReport/123"
   }]
}

Request: GET /service/creditReport/123
Response:
{    "View-info" : [ {
      "description" : "Credit Report 123",
      "details" : [ { "name" : "customer", "credit score" : "750" } ],
      "links" : [ {
        "rel" : "self",
        "href" : "http://serverHost/service/creditReport/123" } ] }
   ]},
   "links" : [{
     "rel" : "loanApplication"
     "link" : "http://serverHost/service/loanApplication"
    },{
     "rel" : "loanAgentOptions"
     "link" : "http://serverHost/service/loanAgentOptions"
    }
   }]
}

Request: GET /service/loanApplication
Response:
{    "View-info" : [ {
      "description" : "Loan Application",
      "details" : [ { "1" : "Name", "2" : "SSN", "3" : "Loan Amount", "4" : "Income" } ],
      "links" : [ {
        "rel" : "self",
        "href" : "http://serverHost/service/loanApplication" } ] }
   ]},
   "links" : [{
     "rel" : "loanApplication#post"
     "link" : "http://serverHost/service/loanApplication"
   }]
}

Request: POST /service/loanApplication
{
  "App" : [ { "name" : "Customer", "SSN" : "111-11-1111", "Loan Request" : "10000", "Income", "25000" } ]
}

Response: HTTP: 200 OK, { "result" : "Accepted for processing" }

At the 'Accepted'  point, the UI interaction with the loan agent (Figure 1) is completed for this use case. The result is that the loan application is uploaded, inserted into a database, and an Activiti BPM "loan application"  process instance is kicked off:

http://erbium.3phasecomputing.com:8080/activiti/fig-2.jpg

Figure 2: Activiti Process, Loan Examiner review

Discussion:
The UI process  in Figure 1 is typically implemented by a state machine that either runs in the browser, as in a single-page web app, or on the server, as in a template-driven MVC framework. In any of those implementations, there comes a point where the UI process reaches the end state, as in Figure 1. At that point, the Activiti process, shown in Figure 2 must be created. These could be handled today by making calls to an Activiti-REST endpoint implemented with RESTlet and custom code which in turn invokes the Activiti API to create the Activiti process shown in Figure 2.

The developer's implementation process is:
1. Use Activiti Designer to create and manage the business processes.
2. Use some other tool (e.g. front-end designer, Spring MVC, …) to manage UI processes
3. Bridge the UI process(es) to the business process with Activiti REST services.

Another Way?
If you're thinking "the UI processes and business process are all really one process", that's the idea. The trouble is that most UI processes are already implemented in their own state machines and then bridged into Activiti with an external-to-the-tool mechanism.

But, Activiti Explorer current includes a feature for human tasks to link to a Vaadin form. Users who are assigned these tasks have an inbox item added for each process instance to which they are assigned. That's a convenient mechanism that may solve specialized workflow situations, but this just links a basic form to a user task inside the Activiti Explorer tool. It doesn't address the question of custom and complex web application UIs.

Suppose instead that we could create the Figure 1 UI process with Activiti Designer. We could link the terminus of Figure 1 with the start of Figure 2. Additionally, the loan examiner has a separate UI process used to view and decide whether to approve or deny the loan request. That UI process (not shown) could drive the exclusive gateway choice in Figure 2.

Adding UI workflow into Activiti Designer and Activiti, either through some seamless links with existing frameworks or by integrating an MVC mechanism, would have significant benefits, including:

- UI process diagrams would exist for applications in a form consistent with present Activiti process diagrams. This would make all human-interaction process, not just the long-running business process, accessible to business analysts.
- Custom UI integration with Activiti wouldn't require RESTlet (or similar) development.
- Since Activiti Designer would be enhanced to create UI process diagrams and link UI processes with business processes in a consistent manner, anyone familiar with Activiti Designer would have an easy time grasping UI process diagrams.
- A UI state machine could be part of Activiti and encourage the development of fully REST-compliant, HATEOAS applications. Such apps could take advantage of content negotiation to manage multiple UI process versions. This would complement activities multi-version process support.
- UI processes could have a standard way to interact with system tasks, just as the the present Activiti processes do.

Kind regards,
Kevin Limperos
klimperos@gmail.com

[trademak]

Hi Kevin,

Okay I understand it a bit better now.
At this moment we don't have plans to add support for this.
But if you see possibility to contribute in this area that would be welcome.

Best regards,