Mind The Gap

"The ultimate value of SOA is the ability to combine automated business services to create new market offerings that may reduce time-to-market and development costs."

This statement was made by Terry Borden and Bill Mitlehner in chapter 4 of the Secrets of SOA. I find this statement very interesting since this is exactly was Adobe LiveCycle ES offers.  This new release has been completely re-designed to enable you to visually "string" document services together to match your requirements. Now, I say document services because that's what we are in the business of selling. But don't let that fool you. The LiveCycle ES architecture is built on SOA principals which enable extensibility and flexibility beyond just documents. Mike Hodgson wrote up an excellent article on Adobe DevNet on how to deploy your own POJOs in LC ES 

Everything LiveCycle sits on what we have dubbed the Foundation. The foundation is powered by a service container which exposes two types of services:

• Packaged POJO (Plain Old Java Objects) classes: Java class accompanied by a component.xml file which describes which methods, inputs and outputs are supported by the class.
• Orchestrated services: Using Workbench (Eclipse based graphical editor), a designer drags the above mentioned packaged POJO classes onto a canvas and links them together based on business rules and/or application requirements.

In each case, once the service is activated, it is registered in the invocation layer which automatically creates invocation methods (endpoints) for that service. The default endpoints are: Web Service, Flex Remoting and EJB. Additional available endpoints (configured manually) are: Watched Folder, Email and Task Manager (only used in conjunction with LC Workspace ES).

The latter type of service (Orchestrated Service) is exactly what Terry and Bill are describing in their chapter. LiveCycle ES provides developers and business analysts with the ability to build processes in a graphical environment, set service properties using property pages and link services together based on their requirements. The key here is that the second that "process" is activated, it is deployed within the service container and from that moment on, is available just like any other service. Of course, there are security constraints that are applied, etc. The point is that very few people understand the power and flexibility that LiveCycle ES provides. With this introduction, I will post several examples in the next few weeks that illustrate my point.

Get the LiveCycle ES Trial now

Posted by Marcel Boucher at 09:09 AM | Permalink | Comments (0)

Regardless of the vertical that you are in, one of the most challenging obstacles to overcome is connecting mobile agents to back office processes. Once that agent leaves the connected world and begins his/her day interacting with customers, suppliers or citizens - something bad happens... All that investment in technology in the back office to increase efficiencies and save money falls apart.

Those field agents are collecting valuable information that needs to be processed as soon as possible - but how does that information make it back into the SAPs of the world? OK, maybe I am going a little over-board here... Many organizations have built custom solutions to bridge that gap or have found some specialized application that does most of what is required. Hmmm, how do we get this application installed on all of the mobile devices the field agents use? And what happens when Fred (good old Fred who built the custom application) leaves the company or gets a promotion? Who is going to maintain that app?

OK, that was a long-winded intro for someone who hasn't posted on his blog for a while... I guess I have too much to say, and not enough time. But wouldn't it be cool if you could have an application that runs on a free runtime provided by a trusted vendor? And you could use this runtime to easily push new applications out to those laptops? And what if that application could automatically detect if it has connectivity to the network or not? And what if it could seamlessly continue to function as if it were connected and automatically store all of your work and automatically submit that work as soon as network connectivity is detected? Now that would be cool!

Well let me introduce you to a sample application I created to demonstrate all of that craziness. This application was built using Flex Builder 3 Beta 2 and runs on AIR Beta 2 . The goal of this sample application is to demonstrate how AIR can help you easily build Rich Internet Applications with the power of off-line and PDF integration.

I called this sample application the Equipment Requestor because I wanted a simple use case that would not overshadow the base message here. The idea is that you are a field agent that may or may not be connected to the network. Each request that is completed and submitted kicks off a business process within the back office. Of course, I am using LiveCycle ES as the process engine (more to come on that - I have lots to say about ES - believe me). The business process in this case is pretty lame - accept data in XML format, merge it with a form template to generate a PDF document. Then, apply Reader Extension rights to that document so that the user can digitally sign the document, etc.

Now, this sample app needs some way to store the information collected by the agent. Not to mention the submission data while off-line and the PDF documents that get returned by LC ES. Since beta 2, AIR provides an embedded database engine - SQLLite. Sounds like a plan to me! When the sample app loads, it looks to see if a local database exists; if it doesn't - it creates one, if it does - it loads what's there. When the users enters data into the request module of the app and clicks submit,  then we need to know if we are on-line of off-line. Well AIR to the rescue again. A NetworkMonitor API is provided that allows you to easily detect network availability. In the sample app, I indicate availability with a traffic light located in the bottom right corner. If there is network connectivity, then the submission is executed in real-time. LC ES is called, the form is rendered and rights are applied. The result is a PDF document send back to the app. That PDF document is then stored in the local database for later viewing.

Oh yeah, AIR does PDF too. So the PDF is stored in the database and we need to enable the end-user to view that document. Well, we use the HTMLControl included with AIR and tell it to display the PDF. The HTMLControl uses the Reader plugin (just like any other browser) to display the PDF. The user can interact with that PDF - digitally sign it, add comments, etc

.

Get the application here.

Get the source here.

For more details on the AIR features I mentioned, Mike Chambers authored an excellent article here.

Posted by Marcel Boucher at 05:54 PM | Permalink | Comments (0)