Posts tagged process
Process Recordings are stored in the /GDS/audit/workflow/ directory.
By default, the maximum number of recordings that can be stored is set to 50.
The value for maximum number of recordings can be configured via Workbench:
Read the complete post at Adobe LiveCycle blog.
Solutions over ADEP have introduced the concept of an application context (aka app context), which can be seen as a unique identifier, that various server side modules use to identify the execution context (from the current execution thread) and process requests in context of that solution. For instance, when persisting content/assets onto the CRX repository, the platform’s persistence module (official known as Platform Content) uses the current (invoking) app context to determine where to store the content/assets, and what configurations to use (which would typically be different for different solutions). See snapshot below, indicating the solution specific content areas.
Note that the storage location is /content/apps/cm for Correspondence Management, and /content/apps/icr for Integrated Content Review, which happen to be the app contexts for the two solutions.
Since it is essential for the server to identify the execution context, if you do not set or establish the application context before you make calls to the solution APIs, you will encounter a server error that says : “Unable to fetch application context“. To set the app context, use one of the two methods:
App context in your Flex application
If you are invoking a solution API from a flex application, ensure that you set the app context using:
var appToken:AsyncToken = com.adobe.ep.ux.content.services.search.lccontent.LCCQueryServiceFactory.getInstance().setAppContextService("/content/apps/cm"); // setting app context for the CM solution
appToken.addResponder(new mx.rpc.Responder(<your success handler>, <your fault handler>));
App context in your Java application
If you are invoking a solution API from a java based application, ensure that you set the app context using:
com.adobe.livecycle.content.appcontext.AppContextManager.setCurrentAppContext("/content/apps/cm"); // setting app context for the CM solution
The app context concept is also used (or rather leveraged) in other scenarios such as driving solution specific Building Block (BB) configurations. Since a Building Block is meant to be reusable across solutions, it exposes certain configurations that can be different for different solutions. Hence, the BB needs to behave differently depending upon the context in which it is being used or invoked. Below is an example where the Data Dictionary BB is used by two solutions – CM and ICR – and has configurations specific to each solution, lying within the solution’s specific app context - /apps/cm for CM and /apps/icr for ICR.
Original article at http://blogs.adobe.com/saket/solutions-and-the-application-context/.
Recently I have been seeing reports of stalled / failed processes, both short-lived and long-lived. It turns out that in some cases, the process developers were updating processes on their live systems without taking due precautions. The following post is to explain what is actually happening under the hood, and why you can’t simply “hot change” a process.
A simple process
Imagine you have a process called MyNotify with two steps in it: a first task (not start point) AssignUser, and a second task SendEmail. Pretty straight forward.
You have deployed this process, and process instances are merrily being kicked off. Great. Now you realize that you don’t want the AssignUser task; rather, you want a Workspace Start Point. Remove the AssignUser task, configure the Workspace Start Point to open the same form as you had in the now deletd AssignUser task. Save and deploy.
You may now start getting calls from your users saying their form submission never resulted in an email. Upon investigating, you will likely find errors saying that “Job ID could not be found for Job [...]“.
Oh no. What happened?
Tasks not found
Let’s wind back to where there were two steps. When a process instance is kicked off, what happens is that an entry in the database is made saying that process MyNotify has been kicked off by user “Alice” (for example), and it has been assigned to Alice, in the AssignUser task.
When Alice submits the form, LiveCycle goes to its database and checks the process – Alice just submitted the AssignUser step, so it checks MyNotify for an AssignUser step, and figures out what to do next from that.
If you have deleted the AssignUser task from MyNotify, LiveCycle will be unable to determine what to do next – and stall the process instance. Future instances should work fine (they are before the change point), anything that was at the SendEmail point in the process will be fine as well (they are after the change point). It is specifically process instances that are in a state that could be affected by the change that risk failure, and that will happen without possibility of roll-back or recuperation (bar performing some incantations in the database to recuperate the data, and then constructing some half-processes to mimick pre-change parts of the changed process, in the hope of pushing the data onwards — a lot of avoidable hassle, itself prone to failure).
It is understandable that you may think that if the process were modified, already-running processes would continue with the older version. This is not so, or at least, not in this scenario.
When kicking off a new process instance, LiveCycle does not automatically make a copy of the process to be followed should a new edit of the process come into existence. Maintaining a copy of all the configurations of a process for each instance created would cause extremely severe performance issues on the server, so a more de-coupled implementation serves best. The work of ensuring that a new copy of the process configuration is created is left up to the process developer.
Once a process is deployed, there are only two “safe” ways of updating the process.
The first is to create a new Application version, and when all the new changes are made, deploy the new version.
- All old instances will continue their course in the old version.
- Workspace processes will kick off in the new version
- Calls to the old version of the process will still call the old version
Once you have ascertained for sure that NO more processes from the old version are running, and that no applications rely on the old version, you can safely undeploy it from runtime, and delete it if you so wish.
When will references point to the new version automatically?
Having done this, all references to sub-processes inside the same application will be updated, as will all resources referenced relatively inside the application. For example, MyApplication/1.0/ProcessA can reference /FormA (in Assign User tasks for example) which means “the current application’s version’s FormA”. A sub-process on the process-workflow convas will be referenced relatively if the sub-process is contained inside the same application.
When do you need to update references manually?
Take special heed however — processes and resources that do not reside in the same Application do not see their references updated — they are absolutely referenced. If MyApplication/1.0/ProcessA is upgraded, it will not change the references to, for example, OtherApplication/1.0/OtherProcess. Similarly, if we upgrade to OtherApplication/2.0/OtherProcess, then MyApplication/1.0/ProcessA will still point to OtherApplication/1.0/OtherProcess.
Finally, note that if you create a new version of an application, all resources and processes are copied over with it with new version numbers too, and any textual references to other resources remain the same. So if MyNotify/1.0/ProcessA has a variable referencing MyNotify/1.0/FormA, then MyNotify/2.0/ProcessA will also reference MyNotify/1.0/FormA ; the same goes for resources uch as XDPs, XSLTs, and any other resources stored in an Application. The reason for this is that these references are stored as “strings” (pieces of text) and Workbench cannot, upon creating a new version, differentiate what snippets of text all through the Application are versions to update, what versions should not be updated, and what strings do not actually contain versions at all.
Down time (clean “brute force” update)
The other way is to plan downtime.
- Prevent people from kicking off new processes
- Let all processes complete
- … and only then deploy the new edit of the process
You could choose the second method to avoid having to update references to resources, but it would defeat the purpose of having this versioning at all and does, unavoidably, incur the overhead of a downtime.
Original article at http://blogs.adobe.com/an_tai/archives/143.
In Adobe LiveCycle ES2 the Workbench property sheets have been overhauled to simplify and streamline application creation. Here are a few examples:
Basic | All filter toggle
Most property sheets in ES2 now include two modes — Basic and All. Basic presents the most commonly used settings, while All will present you with all available settings for the service.
Render PDF Form
The FormsService:renderPDFForm service has been greatly simplified, and thanks to the new asset picker there is no longer a need to hand type URIs. Here is the new service in Basic mode.
Auto Discovery of Credential Alias Names
You no longer have to look at the adminui to determine the available aliases for Reader Extensions or Signing credentials. This feature applies to Apply Usage Rights, Sign Signature Field, Certify PDF & Certificate Encrypt PDF.
Original article at http://livecycleapps.wordpress.com/2009/10/21/livecycle-es2-highlight-property-sheet-enhacements/.
Record and Playback is often considered the most valuable debugging tool in LiveCycle. It allows you to record then step though the execution of a process, to examine the variable values, routes taken etc…
The following Record and Playback improvements were made in ES2:
- A visual indicator (a red dot) will now appear when recording is activated for a particular process
- You can manage process recordings at a global level (Start/Stop/Delete etc…) This allows an administrator to easily disable all recordings on a server.
- You can activate/deactivate recordings for an entire application in a single click
Original article at http://livecycleapps.wordpress.com/2009/10/21/livecycle-es2-highlight-record-and-playback-enhancementso/.
There are situations where a LiveCycle system administrator has to (globally) turn off all process recordings that process developers may have enabled.
One of those cases is where the load testing team prepares the system for a high-volume load test. If recording is turned on for any of the processes involved in the load test, the filesystem-based GDS folder will experience high disk write I/O which will skew performance data (even if the GDS is configured to target the database). There is also the risk that the filesystem will run out of disk space.
To prevent this from happening, you can set a property of the AuditWorkflowService called ‘maxNumberOfRecordingInstances‘ using the AdminUI. Setting this to 0 (the default is 50) and saving the change will in effect turn off all process recording globally. There is no need to re-start LiveCycle. See screenshot below:
Original article at http://blogs.adobe.com/livecycle/2011/03/how-to-globally-turn-off-livecycle-process-recording.html.