Architecturally, LiveCycle ES is an extendable service container and a set of tools to use these services. From the functional point of view, LiveCycle ES services can be grouped as foundation services and solution services.
Foundation services provide basic functionality such as querying or modifying a database, reading and writing to the filesystem, sending and receiving messages from a Java Message Service (JMS) queue, or sending and receiving emails.
Solution services relevant to this chapter are further grouped by LiveCycle ES as two components:
Data Services is software that enables messaging between a Flex
frontend and a Java application server. It was known as Flex Data Services
in the previous releases of Flex. The services of the former component,
Process Management ES, allow you to programmatically start an instance of
the process, query tasks available for a given user, complete the tasks,
retry the stalled tasks or terminate them, and more. Importantly, any
business process that you design automatically becomes a new service, with
a single operation, invoke().
All current implementations of LiveCycle ES are built on top of JEE server technology and require an EJB container. For the full list of LiveCycle ES 8.2 services, you can view online references at http://help.adobe.com/en_US/livecycle/8.2/services.pdf.
The ecosystem of LiveCycle ES service components, tools, and technologies shown in Figure 10-8 is from the LiveCycle ES documentation. Don’t get overwhelmed with the number of the diagram blocks, such as those for Forms ES, Digital Signatures ES, and other solution components that deal exclusively with PDF technology; these are beyond the scope of this book.
Services hosted by LiveCycle ES get invoked through endpoints. You can call the services using the Java API and SOAP. On top of that, LiveCycle ES facilitates the invocation of services by sending an email or by dropping a file in a so-called watched folder. The service can have many different endpoints:
EJB endpoint (otherwise called the Java endpoint)
SOAP endpoint
Email endpoint
Watched folder endpoint
Notice the unfortunate terminology conflict between Flex and LiveCycle developers. Flex developers know endpoints as channel-specific artifacts, such as the AMF endpoint or the HTTP endpoint. Meanwhile, LiveCycle ES folks think of the endpoints per service. From the Flex perspective, LiveCycle ES endpoints look more like a Flex destination, which in the Flex world is an order of magnitude smaller than an endpoint.
For further convenience, LiveCycle ES supports a universal Flex
remoting destination, so you can invoke the service’s methods via the
RemoteObject tag. This destination is
serviced by the
MessageBroker of the web application
remoting, deployed as a part of LiveCycle ES
installation with the following URL:
//<server>:<port>/remoting/messagebroker/amf |
The previously mentioned (LiveCycle ES) endpoints are applicable
to any service. As mentioned already, any LiveCycle ES
process is also a service, albeit with a single
operation—invoke(). To start a LiveCycle ES
process through the LiveCycle Workspace ES, you
must add an additional TaskManager
endpoint. Figure 10-9 shows a snapshot
of the LiveCycle administration UI after adding the TaskManager endpoint. The rest of the
endpoints get created for you automatically.
You are not limited to existing LiveCycle ES services. The component model of LiveCycle ES is easy to extend with custom services. Custom services are packaged and deployed as JAR files. These JAR files are also known as data service components, each carrying one or more services. Using Java you can write your own services, jar them along with a component descriptor, and deploy them into LiveCycle ES.
For instance, if you need to query the status of the purchase order, you may use the foundational Java Database Connectivity (JDBC) service. Alternatively, you can write your own Java class with JDBC code and expose its public methods as operations of your custom service. Then, while modeling the business process, you can seamlessly mix the services provided by LiveCycle ES with your own. Every business process is a service of itself, so processes can invoke other processes.
Figure 10-10 illustrates the tree of LiveCycle ES components after FarataSampleComponent.jar has been deployed and its services have been activated.
The important part of the LiveCycle ES ecosystem is its toolset. The Eclipse-based Workbench gives you features such as visual design, deployment, and debugging of the business processes as flow chart–type diagrams, in which operations of the LiveCycle ES services appear as flow-chart building blocks (see Figure 10-11).
Your old pal Adobe Flash Builder, which is also based on Eclipse, is yet another LiveCycle ES tool. A custom Flex application can enable a user to start instances of a business process; investigate tasks assigned for a particular user; and facilitate task completion, forwarding to another user, locking, and so on.
You also get a LiveCycle ES Administration Console (partially shown earlier in Figure 10-2). The current version of the Console is an upgrade of the previous HTML-based one, with a few minor patches coded in Flex. This chapter explains relevant parts of the Administration Console with regards to importing the sample processes, custom components, and advanced user management.