Solution Spotlight: A look inside Integrated Content Review

I’d like to continue my Solutions focus this week with a look at the architecture of another solution built on top of ADEP – “Integrated Content and Review”.

This solution was originally designed by our Solutions Engineering team to help manage document approval work flows. This worked by authoring a “template” that defined stages in a review with participants in each stage. One of the great things about that solution (compared to a typical BPM process) is that it was dynamic. You could actually tweak the review participants while the approval workflow was “in flight”, or even force it into another stage from a management console.

The team took this concept a step further, by building “Integrated Content Review” on ADEP with a focus on Creative Campaigns (for example advertising). In addition they provided integration with Creative Suite for creative professionals to interact with the solution right within Photoshop.

If you would like a look at the live Integrated Content Review solution, check out the YouTube recording made this week on ADEPDevelopers

Here is a high level architecture diagram of how the Solution Engineering team designed their solution, pointing out some important aspects of ADEP it relies upon:

(Click to enlarge)

As in my last example, the solution is presented through a web portal application that takes advantage of ADEP UX Components (a design technology for end user applications, see: Craig Randall’s post at what is a UX component)

The solution is constructed again using “Building Blocks”. These Building Blocks (you see two of them) contribute both UX Components to the web application and additional Services that run on both the Experience Server and Document Server. Building Blocks are individual Packages that Adobe and our partners use to deliver consistent repeatable solutions. For example, Integrated Content & Review could share these Building Blocks with other solutions that need similar functionality (such as creating a project schedule)

Looking into the Building Blocks used by Customer Communications we see:

Project Management”. This Building Block provides the UI and Services needed to manage multiple “projects” that might run simultaneously during a campaign. These projects can be related to each other (such as one project dependent child projects). Projects can also have “assets” which are work items that need to be produced during the project according to “schedule’ of participants who need to review and approve the assets.

Here are some interesting points to note about the design:

  1. Projects are defined as “templates” which get stored as content in the CRX Repository via Data Services (with our built an “Assembler” for JCR). There is a Project Manager Core service that provides all the operations necessary to create and update project templates or even create a new template that extends from a common base template. These project templates are based on the Apache Velocity project.
  2. There is a Work Item Handler which is responsible for scheduling activities needed for assets in a project. For example, creating a Task for a creative professional to provide an image. The Work Item Handler invokes a service in the RCA Building Block that in turn manages the events needed to trigger notifications and work flow processes.

Review & Comment”. This Building Block (also called “RCA”) provides the UI and Services need to manage a review cycle for content. That is the initiation, revision, revocation and update of a review for “assets” that are being created as part of a project.

Here are some interesting points to note about the design:

  1. A Template Engine (Apache Velocity) executes the Template in order to to trigger “schedules” that involve assigning review tasks for project assets at different stages of the project.
  2. The Building Block contains a service used to dispatch events used by the solution to trigger notifications or to advance a review stage to the next reviewer. This eventing system is internally based on Spring Events.
  3. The Scheduler Service is used to actually trigger Process Management Tasks on the Document Server by invoking Orchestrations that are provided as part of the Building Block. All such invocation from the Experience Server is performed using the Document Services SDK. When stages of an Orchestration complete there is a call back mechanism that helps the Scheduler manage the review, for example when a review Task on the Document Server has been completed. This is performed using a DSC that calls back to the Experience Server.
  4. Sometimes a Task might not be to review existing content but to create new content. In this case the Scheduler can create a Task that will be visible in Photoshop as part of a “Task List” UI (part of Project “Salsa”). A user in Photoshop then creates the requisite asset which then gets used as the payload of the Task he/she completes.
  5. The Building Block takes advantage of PDF as the standard format for all assets being reviewed and will convert assets to PDF automatically when needed. This relies on the PDF Generation and PDF Assembler Document Services running on the Document Server.

These Building Blocks are deployed on ADEP (both Experience Server and Document Server). Document Server integration is of particular importance to this solution because of the reliance on Process Management (used by RCA to generate Tasks and route them to end users). In addition the solution depends upon the Document Server for Identity Management (Users and Groups) typically integrated with an organization’s LDAP.

There is some more information about this solution on adobe.com at: Integrated Content Review