My Developer Lab at Adobe MAX

This year at MAX I have prepared a developer hands on lab session with Seth Reilly called, “Creating Mashups with ADEP’s Composite Application Framework”.

During the session we build a composite application from scratch using all the cool new ADEP features in Flash Builder 4.5.1. Then we dive into a really interesting use case that mashes up existing Flash UI components, Services, HTML and JavaScript to build a fun application. We start with a simulated stock quote streamer (yes, I know .. but stay with me here!) and then we build it out to show a Google Map which automatically jumps to the city location of the company whose stock you select. Pretty nifty, eh.

Here is a screen shot (after some deliberately loud skinning!)

(Click to enlarge)

Here are the basic points we will hit in the session:

  1. Using Flash Builder to author, deploy and debug a Composite Application
  2. Adding a “Service” to your Composite Application. In this case an address look up.
  3. Adding an HTML Tile to your Composite Application In this case an HTML and Action Script Tile to drive a Google Map
  4. Communicating objects between Flex Tiles and HTML. In this case we share an Address Object and access it in JavaScript using JSON to reset the Google Map when you choose an address.
  5. Tips ‘n Tricks for Skinning. We apply a .CSS and a new MXML Skin to the application, for example allowing you to drag & drop the Tiles around within the application.

If you are lucky enough to be going to Max, come check out the Lab, grab a workstation and follow along. We start at 5:00pm sharp on Monday October 2nd in the ADEP Labs area and the session is called, “L2540 – Creating Mashups with ADEP’s Composite Application Framework”

If you would like to read the full tutorial, check it out here: http://ep.adobe.com/content/max/L2540_Gilchrist_CreatingMashupswithADEP_Final.pdf

Happy Hacking –

Gary.

 

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

Solution Spotlight: A look inside Customer Communications

I thought I would take a slight detour from the core ADEP Platform frameworks this week and share with you some insight on one of our Solutions built on top of ADEP, “Customer Communications”.

This solution was designed by our Solutions Engineering team to address a pattern seen over the years with our Document Server customers, particularly financial  institutions. As part of a typical document based workflow (like replying to a dispute initiated by a customer on a web site) it is necessary to quickly draft a letter based not only on common paragraph segments but dynamic data; say the personal information of the customer and the legal requirements of the State / Province in which the dispute was made. Such letters might need to be crafted on screen by a business user or they might be generated automatically.

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:

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 http://craigrandall.net/archives/2011/06/what-is-a-ux-component)

The solution is constructed using “Building Blocks”. The Building Blocks (you see three of them) contribute both UX Components to the web application and additional Services that run on the Experience Server. Building Blocks are individual Packages that Adobe and our partners use to deliver consistent repeatable solutions. For example, Customer Communications shares some of these same Building Blocks with other solutions.

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

  1. A “Data Dictionary”. It is used to manage all the templates and letter assets that are used to generate letters. This data is stored in the CRX Content repository (JCR compliant). The Data Dictionary also integrates with external sources of data (like SAP Web Services or custom databases) to get data used in letters such as customer address details etc. Both the storage of letter assets in the CRX repository and integration with third party data sources is provided via Data Services as a standard framework in the Experience Server.
  2. An “Asset Composer”. This provides the UI and Services needed to author new letter templates and letter assets (paragraphs). The Asset Composer integrates with the Document Server to render letters (needed during authoring) by invoking customizable Orchestrations which in turn rely on our standard Document Services. It also persists those assets and letter templates in the CRX repository, again using Data Services.
  3. An “Expression Manager”.  This is a technology for auto completing additional data (for example calculating an age based on DOB) as well as data validation (required fields, formatted strings etc.). It offers a server side service that is used by the Data Dictionary to augment known data (e.g. a customer name and address) with additional derived data as one record ready for inclusion within a letter (e.g. a ZIP code). It also provides UI libraries for defining and calculating these expressions.

These three Building Blocks are deployed on the ADEP Experience Server. In addition to Data Services and CRX, the other technology point of particular need to this solution is Document Server integration because the solution includes a set of customizable orchestrations around generation of letters using PDF Forms and Assembler. This aspect of the Experience Server provides seamless integration with process orchestrations and User Security which is needed at both design time (using Forms to render letters for preview) and run time for generation of letters.

There is some more information about this solution on adobe.com at: Customer Communications

Happy Hacking

-Gary.

By Developers For Developers

Today we launched a channel on YouTube for ADEP Developers. These videos are produced by our own Engineering team to show off the new frameworks available in ADEP.

Any time there is something cool we want to show off, we will throw a video up on this channel. Our first video in the series in by Seth Reilly who shows you how easy it is to install ADEP and get started.

The full channel is available here: ADEP Developers Channel

Almost There

This week we subjected our upcoming release of the Adobe Digital Enterprise Platform to a global “Hack-a-thon” whereby teams all around the world build out a set of applications based upon use case designs with nothing but the release candidate bits. This event is the culmination of a very ambitious journey in a very short time since teaming up with Day Software. ADEP brings together our LiveCycle and Day CRX/CQ technologies to into a new and lightweight platform for developers to build the entire stack for an application around great customer experience – from a front end cloud scalable web tier through to the (ever so important!) high volume back end document processing and workflow.

The results are in. I must say it’s looking even better than we had hoped. Being engineers we never think the product is “ready” and we always want to wait for “tomorrow’s build”. But our application building teams came back in less than three days with feature rich and apps (and yes, bugs too!) that satisfied all the use cases we provided; like an interactive movie browsing application, a web site that lets users submit and track artwork for approval and an application used to generate and flick through iStatements.

This week we enter the last mile as we land this release and bring it to the world. If you would like a little sneak peek at what we’re up to and some of the driving principles be sure to visit our Engineering team’s Blog at http://blogs.adobe.com/eptech.

We’re almost there.

Happy Hacking-

Gary.

Play with my apps

In this post I will share some applications that illustrate a few frameworks we’ve been working on to help developers who build solutions using the Adobe Enterprise Platform. Notice that this blog post has something new. These samples are actually live and running on the internet for you to play with. not just screen shots :)

Modular Content-driven Applications

The first example illustrates modular development of a user interface, such that you can compose an application out of multiple individual components (could be HTML or Flash based). Modular development might seem like an ordinary concept for good application design. But we have done something quite extraordinary in this field. Now you can literally assemble an application by hosting its constituent parts as content within CRX. Then you can modify your application layout and update its individual components administratively after it was first deployed. No need to rebuild and redeploy the whole web application.

The example below uses two separate components (we call them, “Tiles“). One Tile is an HTML application built using Apache Sling (see my previous post). The other Tile is a classic Flex application that shows a data grid. These are two different applications that can be built and maintained separately but brought together to form a “Composite Web Application”.

This composite web application also has an additional surprise. When the HTML and Flex Tile are composed in this way, the client framework used to display Tiles in the browser (or in AIR) permits communication of data and objects between each Tile via a “Shared Global Application Content”. Try entering a “watch” attribute (any string you like) in the Flex Tile, then submit a value for that attribute in the HTML Tile. You will then see this Tile-to-Tile communication in action.

>>> Live Application Link Here

(or click below to see a screen shot)

Displaying Content in Flex

The next example I’d like to show you is a framework we’ve been working on to provide Flex developers ready made UI Components in Flash Builder that make development against our Platform a breeze; particularly for things that we think you might need to do often. Here I show displaying any type of content (images, movies, documents etc.) that you can browse and select from a CRX Repository and display it within a boundary area in a Flex application. This is a very common pattern in many Flex applications today.

Look for the “testdrive” folder and click around the assets within it. You will see that each type of asset gets rendered in the same view which, rather than being built from scratch to handle all these types of content, just uses a Flex UI component that we call the ‘Web Document Viewer”

>>> Live Application Link Here

(or click below to see a screen shot)

Interested? You want code? That’s all coming soon (watch this Blog). But hopefully this might give you some idea of what we’re doing to help developers not only deliver a great user experience, but to take advantage of a new modular and content-driven approach to building applications.

(Acknowledgments: My Thanks to Ankush Kumar and Seth Reilly from our Engineering “Ruck” team for the original samples)

Happy Hacking –

Gary.

Apache Sling for Dummies: What goes where?

For a while it seemed every time I got a web UI working with Apache Sling (HTML, JSP, Flash, whatever) I would always be told that some part of it was “in the wrong place”. Now that I think I know how to do this stuff, I thought I would offer a simple example with “all the bits in the right places” to help anyone who is new to Sling. By the way, I don’t discount the possibility that someone will reply and point out something still in the wrong place. But here goes!

Let’s take one of the most common approaches for a simple web UI and see how it’s done. That would be a JSP used to display some simple HTML with a very simple style sheet.

Let’s say this is the web UI we we want to arrive at looks like this:

Two things to notice right away:

  1. Spot that the URL is /content/samples/testdrive/dynamichtml.html. That URL structure (especially the /content part) is pretty important. It is literally the same as a node path in your CRX content repository
  2. The web page is showing a title and some body text that it claims to be “dynamic”. What does that mean? Well, as we shall see, these values are not literally coded in the HTML but come from “JCR Properties” of the node in the CRX content repository sitting at the end of the node path. We’ll get to that in a minute.

And something else to point out right away: Most web developers would just think, “Fine. I have all this stuff in a WAR file where I just dump my assets (JSPs, scripts, whatever) under this folder within the ZIP structure of the WAR”. Yes you can do the equivalent of that in the CRX content repository, but you’d be wrong and you’d probably get reported to the Sling Police. So don’t do that.

OK. So how do we build this web UI using Sling. Let’s start by looking at the JSP that renders this page:

(Click to Enlarge)

Nothing too special there. But notice the HTML in the JSP is using two variables “currentNodeTilte” and “currentNodeBody“. These variables in turn come from the currentNode binding which gives you access to the JCR node where the .html request was made. But now the interesting part. Where does the JSP go? Maybe not where you think..

First we start by defining a content node (under /content) where requests will be made for a “.html” rendition:

(Click to Enlarge)

There is not much going on here. Just a content node under /content/samples/testdrive/dynamichtml with a few basic text properties (including our title and body). But look at the value for the  property called “sling:resourceType“. That’s where the magic happens and it’s where the JSP lives:

(Click to Enlarge)

So you place your JSP under the /apps folder and reference its location from the the resourceType in your content node. That might seem like a lot of annoying indirection but it actually achieves something pretty cool.

  • Your anonymous end users don’t literally need read access to the JSP, They just talk to the content node and ask it for “.html“. It is then the Sling framework on the server that executes the JSP and returns the requested “.html” rendition of the content node. That’s why, in this case, we have called it “html.jsp“.
  • You can re-use this JSP as the base web application for requests to other URLs. All you need is another content node that uses the same sling:resourceType and sets its own properties for the dynamic text.

Although the JSP is under /apps that reference to “currentNode” still binds to the node under /content where the HTML request was made. Therefore the JSP gets to substitute text in the HTML based on the “title” and “body” properties of the actual content node.

But we’re not done yet. If you look carefully in the JSP you will see that it its HTML references a style sheet. But style sheets are not really part of the base web application. They belong somewhere else:

(Click to Enlarge)

 

 

The style sheet belongs under /etc/clientlibs. Then the JSP simply references it under it literal path in this case, /etc/clientlibs/aep/samples/testdrive/dynamichtml/style.css.

So in summary to build our little web UI correctly in Sling we needed to:

  1. Write a JSP called “html.jsp” and place it under a location in the /apps folder.
  2. Create a node for the web UI whose folder hierarchy matches the intended URL. Then set the sling:resourceType property of the node to point to the location of your html.jsp in the /apps folder. Therefore when anyone requests a “.html” rendition for that node (called dynamichtml) , Sling will know how to do it.
  3. Within your JSP implementation refer to the style sheet .css file from a folder location under /etc/clientlibs.

This example is quite rudimentary. I haven’t even mentioned what to do with SWFs or how to deploy composite web applications (formerly called “mosaic”) . It is the first sample in a new “Developer Test Drive” that ships with our pre-release for the Adobe Digital Enterprise Platform. There I provide a  few such “getting started for developers” examples that run immediately after launching the ADEP Quick Start.

Happy Hacking,

-Gary.

Beyond the “Quick Start”

 

I have been working a lot recently with Adobe CRX and Adobe CQ (previously from Day) as we build the next generation of Adobe’s CEM Platform (“Customer Experience Management”).

Part of my early work was to understand the basic deployment strategy for for Adobe CQ as it exists already used to publish and manage web sites. What better way than by rolling up your sleeves and doing it, which I have now done and encourage all to try.

For anyone already familiar with CQ and CRX you will no doubt be familiar with our “Quick Start”; literally it is a single JAR file that you can double-click, wait for a minute then Voila! you have a complete WCM solution running on your laptop.

But there is more to it in Production, of course. Typically you need to think about both ends of your user base. On the internet facing side, you obviously don’t plan to expose your poor little java process and its Web Listener to the outside world (right?). Also for your internal developers you don’t want everyone hammering away against your live web pages.

This is not just some custom deployment concern left up to the IT department hosting CQ.

On the internet facing side CRX provides a beautifully light weight and easy to set up “Dispatcher” that drops right into your Apache Listener as a Module. It not only lets you filter acceptable URL requests (your internet end users have no business going to the admin UI!) but it actively caches responses so that if the content being requested has not changed, your request does not need to go back through the application stack.

On the internal facing side for web publishing, CQ lets you set up an “Author” instance where you modify and stage web sites and their dependent content. Then you can have it pushed out to a your “Publish” instance, which is fronted by the Apache Listener with the Dispatcher. There are also many controls over how & when something gets published, such as kicking off an internal approval workflow. When the Author is ready just hit “Activate” on your web content (typically a tree) and then it gets synchronized with your Publish Instance. Note that both instances can be separated by a firewall such that the Author runs in your intranet, while the Publish instance lives in the DMZ

Then there is Clustering, but that’s for another day..

Here is a diagram to give you an idea for how this works (click to view in detail)

There is of course a wealth of information on line at Web Content Management

But since I set this up today and was so pleased with how well it all worked, I just thought I would share my experience. Updating a web page from an Author instance, activating it for Publish, then seeing it render through my Apache Listener was a delight to get working. There’s more to this puppy than a Quick Start JAR file :)

Do I need Forms or Form Data Integrator?

I have had some discussion recently on our Forums and with LiveCycle developers around the question, when exactly do I need LiveCycle Forms vs. just using the simple “Form Data Integrator” service bundled with Process Management?

In fact if you just want to merge XML form data in and out of a PDF Form (that is Dynamic XML Form, Static XML Form or Acro From saved as a .PDF file) then you can use either Forms or Form Data Integrator. Here is a great little sample that shows you an application that does the same thing with both Services: Form Data Sample

Form Data Integrator is just a utility for merging XML data with a PDF Form. Forms on the other hand gives you much more control over the rendering process, scripting behavior, origin of the template, even rendering a PDF Form into HTML. For example: Forms API But even more important is that you need the Forms Service to handle any use cases that demand XDP as the file format of your Form Template – such as dynamic rendering with XDP Fragments.

So in summary, most Forms processing use cases will need Forms. But if you only need to merge XML data in and out of a PDF file format form, then Form Data Integrator might be for you.

New LiveCycle ES2 Goodies on Adobe Labs

This week the LiveCycle Workbench team created a new Technology page on Adobe Labs:
LiveCycle on Labs

The Workbench Engineering team is using Adobe Labs to provide you with a whole new set of Workbench enhancements that are all compatible with ES2 plus a new Eclipse Plug-in for Java developers that helps you build Custom Components (a.k.a ‘Custom DSCs’). This approach gives you updates for our developer tooling to try out and give feedback to the team before we release them in future versions of LiveCycle. Also I think you will find them very useful in their own right.

Be sure to comment on the Labs Forum for either the Workbench Add-ons or the Custom Component Builder with any feedback or ideas you have for improvements:
Component Builder Forum
Workbench Add-ons Forum