Posts tagged concept

Overview of the ADEP Document Services modules

- Michael Steward

When LiveCycle became ADEP Document Services all of the existing modules were ported over but I thought it would be useful to revisit them all and see what as new.  This post gives a summary of the modules which are available to any Document Services solution (excluding the foundation services which come with all Document Services modules) and should be familiar to those who have worked with LiveCycle ES1/ES2 in the past.

Business Process Management

Adobe Digital Enterprise Platform Document Services – Process Management 10.0
Process Management allows the designer to create processes which assign and move tasks around a business.  End users can login using the Workspace web application to view and update any task assigned to them.  This module is commonly used in conjunction with the Forms modules in order to create workflows for forms built by the designer.  ADEP Mobile also comes as part of this module allowing your end users to interact with their tasks on the go.

Content Services
As described in one of my earlier posts this one has now been deprecated.  It’s still included for legacy purposes but you should really be using the new CRX service.

Forms Automation

Adobe Digital Enterprise Platform Document Services – Forms 10.0
The bread and butter of many ADEP solutions, Forms is what allows data to be merged and retrieved from forms rendered to PDF, HTML or Guides.  It also allows forms to be assembled from fragments.  If you are designing to form to be dynamic and it doesn’t have a fixed layout then you will almost certainly need the Forms module.  Together with the Process Management module it allows for some fancy data collection and presentation to your end users!

Adobe Digital Enterprise Platform Document Services – Adobe Reader Extensions 10.0
If you need to distribute those forms you’ve just designed to external parties then chances are you’ll probably run into the need for Reader Extensions.  A “rights-enabled” form opened in Adobe Reader allows the end user to perform tasks that are normally reserved for the commercial Acrobat software such as adding attachments, saving a PDF form locally (the most common use case) and digitally signing forms.  Can be used standalone or as part of a workflow.

 

Read the full blog post here.

Project and team hierarchy in ICR

The campaign is the highest layer in the Integrated Content Review object hierarchy. The project is the second layer in the object hierarchy and the asset is the third layer. In fact, an asset is the basic unit of work — a work item — in the Integrated Content Review workflow.

Multiple levels of project nesting are supported.

Assets are actively managed through review cycles and drive all statuses in the campaign. For example, if an asset is late, the status of the parent campaign automatically becomes red. If all the constituent assets of a campaign are on time or green, the status of the campaign is green. Therefore, the status of a campaign is derived bottom-up instead of top-down.

Team member inheritance

Teams are built in a bottom-up fashion. Team members at any level in the campaign hierarchy include team members from lower levels. In other words, a campaign includes all members of a project. A project, in turn, includes all members of the assets within it.

Additionally, at any level in the campaign, a new member can be added directly to the team list. These new members have no responsibilities towards the campaign, but they receive notifications when statuses change. They also get access to the solution interface so that they can proactively see how the campaign is progressing.

For background information, you can refer to the Integrated Content Review Solution Guide.

——-
Original article at http://blogs.adobe.com/samartha/2011/09/project-and-team-hierarchy-in-icr.html.

ADEP Architecture Principles and Choices Whitepaper

Craig Randall, Chief Architect of Customer Experience Management has just released  a whitepaper entitled “The Adobe® Digital Enterprise Platform: Architectural principles and choices”.   The document is available from the Adobe Digital Enterprise Developer Center.   In it, Craig describes the principles behind the design of … Continue reading

——-
Original article at http://blogs.adobe.com/ADEP/2011/09/adep-architecture-principles-and-choices-whitepaper.html.

JGroups and LiveCycle Workspace – Explained

Darren Melanson

First, an elementary explanation of what it is: JGroups is a toolkit that is used in LiveCycle to broadcast group based messages in a controlled infrastructure which by default leverages multicast as a communication mechanism. A much more defined and thorough explanation can be found at jgroups.org. This post is intended to provide some insight into how JGroups is used in LiveCycle ES and ES2 at a somewhat lower level and explain some of the configuration parameters. This post is not intended to be a “how does JGroups work” article.

It is important to note that JGroups is used in other areas of a LiveCycle infrastructure:

  • Gemfire (which LiveCycle uses as a caching solution)
  • Content Services
  • 3rd party application servers that host LiveCycle

This post will only touch upon how JGroups is used in LiveCycle Workspace.

LiveCycle Workspace is a Process Management component that provides a web-based user interface that lets users participate in business process activities. When a user is logged in to the Workspace client, that user has to be kept up to date with any activity that involves them, so the use of LiveCycle Data Services is employed as a communication layer between that client and the server. At any time that an event is triggered that would impact the content being displayed to an end user, that information must be broadcast to the data services layer of LiveCycle Workspace, this is where JGroups comes into play.

Getting into more specific detail, JGroups is used to push internal LiveCycle events, such as task creations, task reassignments and task completions out to the Workspace web application (Workspace WAR). These LiveCycle events will be presented to users logged into Workspace as a toast message indicating what has been added, removed or changed for that particular user.

So, how does LiveCycle Workspace use JGroups?

When a LiveCycle event occurs from TaskManager, a component called the RemoveEventDSC contains a JGroups broadcaster that will use multicast to send a message intended for the JGroups listeners in the Workspace web application. Every instance of the Workspace web application will have a listener where it is set up to only consume messages for which it is intended. When a message is consumed by the JGroups listener in the Workspace server component, an update is made to the data services layer, the updates are consumed when that layer is next polled by the Workspace client.


JGroups has a number of configuration parameters that can be changed to accommodate various infrastructure restrictions. All configuration parameters are setup in an XML file which you have to first export using AdminUI, make appropriate changes, re-import and then restart your LiveCycle environment. Here’s where you can get that XML file: Login to AdminUI as an administrative user, click on Services, then click on LiveCycle Workspace ES2 and finally click on Global Administration, the last button on the screen is for exporting the global settings. Click on that button, it will generate an XML file that you can save locally to work on it. Make a backup of the file before making any edits.

In the XML file (AdminGlobalSettings.xml) that you exported, there are 2 items that are relevant to JGroups settings:

<server_remoteevents_JGroupName>

This is the name of the JGroup that is used for broadcast message consumption; the value stored in this setting is auto-generated and unique for each new environment. The only time you would ever change this value is if you copied a LiveCycle database environment to create a new LiveCycle environment.

<server_remoteevents_JChannelConnectionProperties>

Generally the settings found in this element are valid for most networks, however in some cases some of the settings need to be tweaked to accommodate stricter network policies.

Some examples of elements that “could” be changed:

mcast_addr: (Multicast address) – some subnets require a specific IP address range where multicast is permitted; you have to ensure the network IP Address used for multicast is valid for your topology. As an FYI, IPv4 multicast has a range of 224.0.0.0 to 239.255.255.255.

mcast_port: (Multicast port) – as with the IP Addressed used, the port must be available for the subnet where LiveCycle is running. Generally the port number is rarely an issue to affect connectivity; however each network is different, so if communication issues are encountered with an error connecting on the port specified, you should talk to your network administrator to figure out what port to set.

FD: (Failure Detection) – JGroups has built in failure detection; the timeout setting here says it will wait 3 seconds for a response from an “are you alive” message to another JGroup node. If the response is not returned within 3 seconds, a second message is sent, called a “suspect” message (explained next) – You can increase the timeout setting to beyond 3 seconds, but be warned that if failure detection is happening, it means there’s likely something in your network slowing down communication which should be addressed.

VERIFY_SUSPECT: This is a secondary check if the Failure Detection timeout is reached. Only when a FD limit is hit will this second attempt be run to double-check if a member is really not responding. Think of this setting as a means to ensure that a detected failure is really failed by trying again. You can also increase this value, but also be warned that addressing the actual cause of the unresponsive node is more important than increasing a timeout.

There are other settings in the file that should not be altered, if you are curious I suggest visiting jgroups.org for details on the specifics on those additional elements along with any other JGroups specific details you are looking for.

 

——-
Original article at http://blogs.adobe.com/livecycle/2011/03/jgroups-and-livecycle-workspace-explained.html.

What is LiveCycle Enterprise Suite 2?

Seth Reilly

LiveCycle Enterprise Suite 2 (ES2) is Adobe’s enterprise offering for generating, capturing, and exchanging business information using integrated RIAs, secure documents and automated processes. LiveCycle ES2 helps businesses and governments more effectively deliver engaging applications across devices and channels to customers, citizens, and partners inside and outside the organization. New features of LiveCycle ES2 include personalized rich Internet application (RIA) workspaces, mobile and desktop access to business critical applications, a more collaborative and productive development environment, and a new deployment option in the cloud – allowing workers, developers and decision makers to bring value to their organizations faster than ever before.

If you want to know more, here is the full LiveCycle Enterprise Suite 2 Press FAQ sheet: LC ES2 Press FAQ External Final

—-
Original article at http://livecycleapps.wordpress.com/2009/10/07/what-is-livecycle-enterprise-suite-2/.

Go to Top