« - »

The Approval Service: Lifecycle Overview

24 February 2008

I still need to build a sample “using” application for the Approval Service, just to demonstrate how it might be used, but once I fix and/or work around the last Betwixt issue and wrap everything up into a final .ear file for distribution, that should be it for this little project. Before I do that, though, I thought it might be helpful to go through the steps in the lifecycle of a typical Request for Approval, or RFA. Consider the following illustration:

Approval System Overview

The originating system initiates a Request for Approval by submitting an RFA to the Approval Service. There are three ways that this can be done: 1)  by issuing an HTTP PUT to the service from a browser via Javascript, 2) by issuing an HTTP PUT to the service from a server using HTTP Client or similar techniques, or 3) if the originating system’s server-side code is running in the same container as the service, by just calling the RequestForApprovalManager directly using the insertRequestForApproval() method.

Once the RFA has been submitted, approvers can review the RFA along with any other pending RFA via the Approver’s View page widget, which can be incorporated into any page served up by either the Approval system, the originating system, or even a third, unrelated system. While the list of pending RFAs comes from the Approval Service, if a user clicks on the link to see the details for a particular item to be approved, those details are displayed in a pop-up window that is provided by the originating system (see figure). This is how the Approval Service can remain ignorant of the contents of the RFA: it is the responsibility of the originating system to display the contents, not the Approval Service. The Approval Service has no knowledge of that which is being approved, other than it’s URI.

When a decision is made on an RFA via the Approver’s View page widget, that decision is recorded in the Approval System’s database. That decision is also communicated back to the originating system, again using the item’s URI, via an HTTP POST. This completes the lifecycle of the RFA. The originating system issues the RFA, which initiates the lifecycle, and the receives approver’s decision from the Approval Service, which terminates the lifecycle of the RFA.

Next time, we’ll hopefully wrap things up by posting a new .ear file, complete with a working example to demonstrate the entire process from end to end.


Comments are closed.

Sorry, the comment form is closed at this time.