ImplementationCase: asynchronous activity outside a formal workflow

Motivation

To notify a user when a long-running activity (LRA) is complete.

Story

User wants to run a LRA, possibly a complex archive-query, but does not want to wait for the result. The LRA is not part of a machine-managed workflow; no other operations need to start automatically when the LRA finishes (c.f. IcAsynchronousActivityInWorkflow). User does want to find out fairly promptly when the LRA is done in order to work interactively with the results. User needs to disconnect from the VObs while the LRA is running.

User sets up the LRA in a web Portal, specifying that the LRA should run 'in the background', as an identified job. User disconnects from portal.

Portal understands 'isolated LRA, running in the background' to mean 'single-step workflow, running asynchronously'. It writes workflow instructions accordingly.

Portal starts the the workflow as an synchronous activity on Workflow Engine, as in IcAsynchronousActivity.

Workflow Engine starts the LRA on Service as described in IcAsynchronousActivityInWorkflow.

When Workflow Engine receives notification of an event from the Service running the LRA, it forwards that notification to Portal.

Portal uses the notifications in two ways. First, it logs them all to a file. User reconnects occassionally to Portal and views a page that displays this log, thus keeping up with progress of the job. Secondly, Portal copies the final completion/success/failure notification into an email to user (Portal gets the email address from a Community service).

Discussion

This is a special case of IcAsynchronousActivityInWorkflow (q.v.). It's actually a little more complex than that ImplementationCase as it details the notification of the user. It would be possible to do without Workflow Engine and to have Portal run the LRA directly on Service. This is conceptually simpler...but probably makes more complex code as parts of Workflow Engine would need to be duplicated in Portal. By including Workflow Engine, Portal is made stateless apart from its log file of notifications.

It is unclear what happens if Portal or Workflow Engine are down for some time. Ideally, any missed notifications should be resent, but I suspect that that is too hard to arrange. What is utterly essential is that Portal should be able to detect reliably the completion of the workflow even if it, Portal, was off-line at the time. Intermediate progress-messages are expendable; completion messages must never get lost. The standard for notification may need to treat completion messages as a special case.

-- GuyRixon - 22 Apr 2004