The workflow engine however has three key challenges that require solving for all but the most simple applications, namely;

• Flexible action handling e.g. sending email, integration with external applications – as standard, sending email would require a custom handler which needs to be unique per recipient (user or group)

• Modification without in-depth technical knowledge for complex workflows – this can be an expensive development activity that is required for all but the most simple workflow definitions

• High degree of duplication for the creation of new workflows – workflows and workflow processes cannot be easily reused or shared (ignoring recent product developments allowing workflow definitions to be ‘BluePrinted’) increasing development and testing costs, and the likelihood of defects

In many instances, approval workflow systems created or defined for clients are seldom used when the client has a marketing focussed web team as in these cases offline business workflow is implemented in the production of content and approvals. When the client is in a position where potentially litigious content could be released into the public domain and that content needs to be approved by many departments a simple approval workflow is not sufficient.

For a recent client who required a press release workflow to integrate with an off-line paper based system and that approval groups be dynamic based on content metadata it was soon realised that the standard Tridion approval system would require hefty customisation and that a high degree of duplication would be required to meet all possible combinations of user approval when following the standard Tridion model.

To solve these problems, Amaze developed a user configurable workflow extension that allows customisation of workflow that provides the following features, many workflows for diverse groups and actions from a single workflow definition, integration of external code applications.

At the heart of this solution are two XML based configuration files, one for email recipients and one XML based workflow step definitions. Although it is acknowledged that XML is not ideal for the business user, it is a format that can be easily described, read and machine validated and does not require complex deployment procedures.

The following is an example of the default workflow definition for all Tridion Schema for which workflow is defined. In line 1, the URI would be changed to a specific Schema or Page URI for which the steps correspond. The elements ReviewActions, AdmReviewActions, rejecttoCreatorActions and RejectToWebEditorActions correspond to named workflow steps in the generic Tridion Workflow – error handling is taken care of in the wrapping business logic for the solution.

Each of these steps can have a pre- and post- action for example to check status of dependencies. The Actions themselves define arbitrary VBScript that is executed at that step.

…
<ReviewActions>            
    <Post>
        <Action id="0000" description="Notify Administrators if Needed">C:\code\notifyAdministratorReviewer.vbs</Action>
    </Post>
</ReviewActions>
…

An accompanying configuration file defines email lists that correspond to Tridion user groups. These can then be access via Tridion URI for email sending as per the following example snippet.

<group uri="tcm:0-1443-65568" description="Adm Reviewers">

<email subject="Workflow Auto Generated Mail For Adm. Reviewers">admin@amaze.com</email>

<email subject="Workflow Auto Generated Mail For Adm. Reviewers">admin@amaze.com</email>

</group>

As a result of this workflow extension, the client now has an approval workflow system that can be integrated with their existing business processes with the minimum of duplication, rework and technical intervention. This gives an ongoing saving in time and money for technical development, testing and roll-out.

The specification of the system called for the mapping element to surface content via a search interface with free text, radius and point of interest type options. The search results then calls a further page with a rendered map with search results plotted on the map. Each plotted point is a record in the Tridion CMS and a synopsis of the records displayed on the page. Further functionality allowed the map to be moved (in a similar fashion to Google Maps) and further points outside of the original search radius now visible, to be plotted.

With any integration a loosely or tightly integrated model needs to be considered. In either case there may be technical, business or non-technical requirements that will influence the decision. It may be possible in some cases to argue from either a technical or non-technical perspective that a business requirement can be reconsidered or revalidated.

When planning a solution for this integration it was decided that a loosely coupled solution would be the most practical as it was most consistent with the business case.

Full requirements capture was carried out and analysed and the following technical solution was designed.

The literal key to the solution was the maintenance of a reference known to both systems. The key is generated by the GIS team which does not affect the business requirements although it does introduce a slight overhead on the part of content entry as the key must be sought from the GIS team via a business workflow case before the content can be ‘live’. The reference is stored in Tridion using a Metadata schema assigned to each Component.

The wireframe outlines the functionality of the solution.

• The Mapping Element (1) is rendered via the GIS system.
• Managed content for the selected point of interest (either via search or interaction with the map) at (2).
• Other elements rendered as selectable points of interest are rendered as a list of links at (3).
• Other points of interest based on proximity or search class are rendered as (4).

Mapping content and managed content is retrieved by the client browser using a combination of REST and Web services enabling the GIS component to be managed on a separate network.

This solution and it framework proved adequately flexible to allow it to be used in another GIS application with very little modification and this modification to be primarily to the cosmetic presentation and configuration.