Adobe Content Server – DRM for Commercial eBooks

This product, also known as ACS, is capable of securing content in the ePub and PDF file formats. The product is sold by Adobe partners as a server license, and there are transaction charges incurred for each individual content license granted.

The target market for this offering is eBook or other digital content distributors such as Sony, Kobo, Barnes & Noble or Google. Content is licensed on a one to one basis and rights are applied at the time a specific item is purchased. More specifically, content is licensed to an individual with a specific Adobe ID or Vendor ID, and may not be consumed on reading devices that are not registered with that ID. ACS provides granular control over the rights that may be granted with each content license. For example a book store may sell a popular title for one price with the rights to read it on multiple devices, re-download it a future date and print a range of pages, and may also have the same book listed at a different price with more restrictive rights. Once rights are applied, generally at purchase time, these rights cannot be modified or revoked.

---

Read the complete post at Datalogics Blog.

http://help.adobe.com/en_US/livecycle/9.0/designerHelp/index.htm?topic=000126

http://blogs.adobe.com/formfeed/2010/02/translating_forms_using_xliff.html

Adobe describes Reader Extensions in the following way

Reader Extensions enables document producers to use a Web-based interface to quickly and easily embed usage rights into Portable Document Format (PDF) files that will “turn on” functionality hidden within the free Adobe Reader. These functions are automatically activated when the respondent opens the Adobe PDF document. Customers, constituents, and partners who access a rights-enabled Adobe PDF document can:

• Save the file to their local hard drive
• Fill it out onscreen
• Share it with others to review and add comments using intuitive markup tools like electronic
  sticky notes, highlights, and text strikethroughs
• Authenticate and sign a document
• Submit the completed document electronically

While people generally concentrate on local form save as the most important reader extensions right, there are actually 12 individual rights. Adobe has an excellent knowledgebase article on this for your reference. These rights are

Two elements are necessary to reader-extend a file. The first is code that will appropriately create the rights dictionary in the PDF file. The second, since that rights dictionary is signed with a digital certificate, is to have an appropriate Reader Extensions credential from Adobe. To date, only two implementations of the rights code exist. The first is in Adobe Acrobat, which has the capability of reader-extending forms and documents to limited audiences. The second is a Java implementation, available within Adobe LiveCycle, more recently, the Adobe Java PDF Toolkit distributed by Datalogics. Reader extension credentials for the signature are still fully controlled by Adobe and can also be resold by Datalogics for use with the standalone Java PDF toolkit. This allows OEMs and ISVs to embed reader extensions capabilities within their products.

Acrobat Pro, since version 8 has enabled a subset of these rights. They are 1, 3, 4, 6, 7 and 8. [Acrobat seven also reader enabled documents but only for comments: just enabling rights 7 and 8.] Access to the full set of Reader Extension rights is only available with Adobe server products in the Java implementation.

I will be covering more details and evaluations of Reader XI and rights in the near future… Stay tuned.

The REST endpoint makes invoking the LiveCycle Process a simple ajax call. The JavaScript code below is utilizing the jQuery ajax library (jQuery.ajax()) to invoke the LiveCycle Process and pass in the required input variable, inputXML, to the process.

var params = new Object();
params.inputXML = xml;
		
$.ajax({ 
type: "GET",
data: params,
url:"http://www.yourlivecycleserver.com/rest/async_invoke
/Digital Citizen/process/ScreeningApplicationProcess:1.0", 
success: function(data){        
//execute on success;
},
error: function(data){
//execute on error;
}
});

In this particular case the LiveCycle process is a long lived process and returns the process ID as the result of the ajax call. As I noted at the onset, calling a LiveCycle process from PhoneGap sounds way more complicated than it actually is!

Almost 2 years back I did a quick post rejoicing about JMS removal from LiveCycle and Work Manager API introduction in LiveCycle ES2. It’s been a while since then and this post summarises what benefits we get with Work Manager and what is critical to do in any LiveCycle ES2 + installations so Work Manager works in favor of you and not the other way around.

Important: ALL of the below information is based on my observations and testing against different LiveCycle ES2+ version on different platforms (os/database/app servers). ALL of the below information is related to LONG LIVED processes only. Repeat, LONG LIVED processes. The way short-lived processes are executed in LiveCycle is totally different to long-lived processes and are working the same way and are out-of-scope for this discussion.

Background:

1. Before LiveCycle ES2 came out LiveCycle used JMS to facilitate the Long Lived process execution.
2. When someone or any program invoked a Long Lived process the calls to start a process execution was delivered via JMS message to process engine.
3. This didn’t work perfectly on high load on the servers.
4. Then, we got LiveCycle ES2 version with Work Manager API which replaced JMS (my previous post on it is here)
5. This work manager API (JSR-237) which was a good move forward (in my opinion) to allow container-manageable programming model for concurrent execution of work.
6. Since that LiveCycle ES2 release it uses this work manager API to facilitate the Long-lived process execution. The latest release of LiveCycle is ES3.

The Performance degradation issue

As part of a project I did some investigation into how a long-lived process is executed from start to end. The complaints I heard at that time from some of my colleagues were around LiveCycle 2.5 takes much longer to execute our processes compared to LiveCycle 8.2.

As usual I did process analysis and tried to identify pain points into the process logic… etc but what stuck out the most was the same process took much shorter time on LiveCycle 8.2 compared to default turnkey LiveCycle 2.5 installation. This problem is visible and interesting when you have lot of steps in a process or have lot of sub-process calls.

There is definitely a performance degradation (from total time taken point of view) into the long-lived process execution when your process involves sub-process calls. What it comes down to is around Default value and how Work Manager works.

So this is how work manager works in simplest terms -

1. A request for Long-lived process execution is made. From LC java API or any of the End-Point (aka Start-Point) etc.
2. A job id returned to the caller and a record is created in LC database for Work Manager.
3. Work Manager looks at this queue and starts process execution by doing some other inserts and updates in database tables and work is handed over to Process Manager etc etc…
4. At any point of process execution if it has any sub-process calls then the same process is followed where a message/record is created for new job, work manager looks at that queue and executes the process and returns the results to caller if needed…

Note: For the curious minds.. I’ve attached a mind map file here to provide details on how database level details work. This is based on a blog post done by LiveCycle team.

So now coming back to what the problem is..and why the long-lived process executions are slower in ES2+.

Finding:

As the Work Manager looks at a queue once every minute by default it causes the degraded performance in ES2+ versions. This is a big problem once you have large LiveCycle Application where you have around 40-80 processes getting called to do some work. For small little long-lived processes (without not many sub-process calls) its not that bad.

Solution/Workaround:

So the solution or workaround for this situation is to tell Work Manager to look out for new work more often. Luckily the LiveCycle startup parameters have this setting which you can tweak. I set the parameter to 50 from its default value 1000 (the unit is milisecond) after testing what I needed. So the parameter looks like below on our Weblogic servers.

-Dadobe.work-manager.queue-refill-interval=50

Here are the full set of parameters that you can review and tweak based on need.

• adobe.work-manager.queue-refill-interval
• adobe.workmanager.debug-mode-enabled
• adobe.workmanager.memory-control.enabled
• adobe.workmanager.memory-control.high-limit
• adobe.workmanager.memory-control.low-limit

Huh?:

I was surprised to not see this mentioned in the install guide or any other docs that are published for LiveCycle Es2 onwards. The default is set to so large value that there isn’t any ‘same as before’ performance for bigger LiveCycle deployments.

Few words for friends who work with LiveCycle:

These details provided above are my observations and findings on what we faced on a client project. Please share your experience on above item as I’m really interested to find out if you haven’t got the same issue (where Work Manager queue refill interval is set to too high by default) or tweaking that value has helped in your project.

Let me know if you need sample LCA and I’m happy to provide simple LCA which can be used to measure the outcome before and after the tweaks.

As always, ping me on @pandyaparth on twitter if you want to have a conversation on this or any other LiveCycle stuff!!

Essentially what happened was that within an object tree supposed to be sent from the Flex application to a Livecycle endpoint contained a lot of unexpected null references. Monitoring the AMF remoting traffic with Charles showed however that the data was serialised fine on the Flex side of things. At the other end of the wire though, something clearly went wrong. Even more confusing was that the serialisation seemed to work fine for non-complex data types which led us to the suspicion that the conversion of ArrayCollections to Java generics was setup incorrectly.

Without elaborating on details of coding and configuration switches that can modify how all that works in depth (hint: IExternalizable and java.io.Externalizable are your friends…), I rather want to explain some other configuration settings that a lot of people wouldn’t be aware of, but that are extremely helpful when you run into a possible serialisation problem.

---

Read the complete post at Blog In Black.

Essentially a Livecycle/ADEP DSC is nothing else but a .jar file that’s been crafted in a certain way. Darren wanted to have the .properties file within the DSC and needed to know how to access the file from Java code within the DSC. Here’s a working approach how this can be done:

---

Read the complete post at Blog In Black.

You have no idea what I’m talking about? Ok – here’s the gist: A DSC is a Document Service Component in LiveCycle. Basically it’s a component wrapper for some custom logic or external service integration that one can write and use within the LiveCycle Process Management Engine. One of my biggest complains about and issues with LiveCycle are the lack of community contribution and the lack of good and advanced documentation around the product. So, let’s take this opportunity to compile a few interesting resources around DSCs.

If you’re ever in the need of extending LiveCycle (and most serious users I know are at some point), writing a Document Service Component is one of the easiest ways. To get started, use a tutorial Adobe provides here:

Extending LiveCycle ES software through custom DSC development – Part 1: Create a basic service component

---

Read the complete post at Blog In Black.

You can use the JavaScript APIs that do not require compilation against services-config.xml. Remoting only needs destination-to-channel mapping, and the channel information (url, id) from services-config.xml. Therefore, instead of compiling against the services-config.xml, you create your own ChannelSet, and assign a component (RemoteObject) before using the component. Alternatively, if your browser supports the HTML5 WebSockets, you can use a WebSocket channel, instead of a RTMP channel in Flash, for real-time communication.

You can access reference documentation for the JavaScript API from the jsdocs.zip under the installation directory of LC Data Services.
[Data Services Install location]\resources\client-sdk\javascript

For creating a web-application kindly refer the link: https://blogs.adobe.com/LiveCycleHelp/2012/07/creating-web-applications-using-html5javascript-remoting-client-sdk-with-livecycle-data-services.html

2) Create connector between Apache WebServer and your two LCDS Tomcat server(see apache connector configuration doc).

3) Create a folder “LCDS_Configuration” (any name) in the WebApps folder of your Tomcat servers.

4) Open the .flexProperties file of your sample application and make sure the “serverContextRoot” is /LCDS_Configuration.

5) Place the content of WebContent from your sample application inside the “LCDS_Configuration” folder of both the Tomcat server.

6) Most importantly compile your application against the services-config.xml placed at the location …LCDS_Configuration/WEB-INF/flex.

7) Create a folder “Flex” (any name) in the htdocs of your WebServer.

8) Place the content of bin-debug inside the “Flex” folder of Apache.

9) Dont miss to add JkMount in the mod_jk.conf file.
# Send everything for context /LCDS_Configuration to worker ajp13
JkMount /LCDS_Configuration ajp13
JkMount /LCDS_Configuration/* ajp13