Posts tagged HowTo
- David McMahon
If you have installed a patch or service pack for LiveCycle ES you may need to uninstall this at a later date, or you may have a requirement to document this process fully as part of your installation/configuration documentation.
This information is outlined in the readme file provided with each patch or service pack, and I will just expand on that giving some more detail here. In this example I will discuss uninstalling LiveCycle ES Update 1 SP4 (184.108.40.206), to go back to LiveCycle ES Update 1 SP3 (220.127.116.11) on Windows.
Before installing/uninstalling any patch you should take note of the current versions installed so you can verify your steps have been successful later. Take a screenshot of the About screen, and the Service Management screen from the AdminUI.
AdminUI > About screen (note the Patch version “SP4″ and Service Pack version “8.1.5192.1.284202.47″, and the Patch level of each deployed component “SP4″):
AdminUI > Services > Applications and Services > Service Management screen (note the Component Versions “8.1.5192.1.284202.47″, “8.1.5193.1.279333.70″, etc…):
Before running through the uninstallation process it would advisable to make a backup of your existing configuration in case any unexpected problems should arise. To do this, you should make a copy of the entire LiveCycle installation directory (excluding the MySQL folder if it exists within the LiveCycle directory).
You should also take note of the following configuration properties from AdminUI > Settings > Core System Settings > Configurations:
- Location of temp directory
- Global document storage root directory (Changing this value will result in data loss unless you also manually move the data)
- Location of the Adobe Server Fonts directory
- Location of the System Fonts directory
If you have LiveCycle Content Services ES installed, you should also have the location of the Content Services root directory which you entered during the original installation/configuration process.
Read the full blog post at http://blogs.adobe.com/dmcmahon/2011/12/20/livecycle-es-how-to-uninstall-a-patch-or-service-pack/.
I’m starting a new hands on series for LiveCycle called appropriately: Hands On LiveCycle. This series will give you a complete and working sample LCA (LiveCycle Archive) file that you can import and run on your LiveCycle server. These hands on entries will attempt to solve a real world problem and will start out simple and continue to grow in complexity. If you have a suggestion for a hands on entry you would like to see feel free to let me know!
I’m kicking the series off with a problem that something that most consumers and agencies can relate to. How to handle a form that requires a wet signature, or an actual physical signature on the document.
In a perfect world everyone would accept a digital signature and all forms would be able to be submitted online. However, we don’t live in a perfect world and a good number of companies and government agencies still require a wet signature on a document or form to do business. If you wanted to fill out a form for a financial service or a government request the typical process today might go something like this:
- Download the document
- Print the document
- Fill out the document
- Sign the document
- Mail the document
Once the document is in the mail the process continues:
- Receive the document
- Key in the data in the document to the database
- Store the document on the server
There are quite a few things that can go wrong with this human centric process. The document could get lost in the mail, the user could fat finger the data, causing delays, or the document could be stored in the wrong place. There are several ways that this process can be improved, just by using LiveCycle Reader Extensions, the LiveCycle Foundation Services and the free Adobe Reader (Barcoded Forms is now included with the LiveCycle Reader Extensions service) Using LiveCycle Reader Extensions allows you to automate several pieces of this process and in some cases more, depending on how a company or agency is willing to accept the form.
For this LiveCycle Hands On, it is assumed that the document will be filled out, printed, signed and mailed in by the applicant. Once the document arrives at the agency, it will be scanned and placed in a folder that is watched by LiveCycle. Once LiveCycle sees the document in the folder it will be processed, the applicant data will be stored in a database and the document will be written to the file system.
This process could be made even faster by removing the snail mail portion if the agency was willing to accept a document by email. If so, the applicant could scan the document themselves, attach it to an email and send it to an email address that LiveCycle monitors. Also, with the use of Reader Extensions, the user can now save a copy of the completed form to their hard drive.
Download the zip file: Barcoded_Form_Demo.zip
The zip file for this hands on has a .lca file containing a form, some sample data and a process as well as a sample filled out form and a SQL script to create the demo table. The SQL Script should be run on the server that is hosting the LiveCycle Database and should use the adobe schema. The form will work either as the PDF file included, or if the form is printed out and scanned. LiveCycle is able to decode the information from the barcode either way.
The Barcoded Form Demo Process:
The process is broken down below into steps and the operations used.
- LiveCycle recieves a document from the watched folder to start the process
- LiveCycle extracts the data from the barcode and adds it to a XML variable. Operation: Decode Category: Barcoded Forms
- LiveCycle extracts the XML form data from the barcode data and stores it in an XML list variable. Category: Extract To XML Service: Barcoded Forms
- LiveCycle sets the form data to the first element of the XML list variable. Operation: Set Value Category: Foundation
- LiveCycle inserts the data into the database. Operation: Execute SQL Statement Category: Foundation
- LiveCycle writes the document to the file system. Operation: Write Document Category: Foundation
Please feel free to ask any questions in the comments and I will try to answer them as quickly as I can!
Original article at http://www.underprise.com/2011/05/20/using-reader-extensions-and-barcoded-forms/.
Converting DOC(X) in LiveCycle PDF Generator yeilds error: ALC-PDG-019-060-Encountered error while importing the XMP file.
When PDFG ES2 converts Word documents, it extracts the metadata and compiles it as an XMP for the PDF.
There is a known problem however, when a file contains custom metadata: PDFG cannot compile the XMP properly for such files.
To check the metadata in the DOC, open Word.
Use the MS Office menu (the big round one, top left) : Prepare : Properties
A small yellow info bar will appear above the editing area.
In that area, Click “DIP Properties – …” and select “Advanced properties …”
Go to the “Custom” tab
If there are items in the space at the bottom labelled “Properties”, then your DOCX is likely to fail to convert.
There are two solutions to this:
1/ Log on to the LiveCycle Admin UI
2/ Go to Services : PDF generator : File type Settings : [your file type settings]
3/ Open Word file type settings
4/ Uncheck “Convert document info”
This will prevent PDFG from trying to extract and convert the Word metadata – thus excluding the problematic custom information
2) Obtain the patch
If you have an Adobe Platinum support agreement, you can contact technical support and request the patch.
Original article at http://blogs.adobe.com/an_tai/archives/64.
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.
Although you can start your ADEP Experience Server by double-clicking the Quickstart JAR file or the Windows batch file, most people will find it convenient to install the Experience Server as a Windows service. It will configure the Experience Server to start automatically when your Windows restarts and, helps you control the start and stop operations of the Experience server by using the Services control panel.
Install Experience Server as a Windows service
To install a Windows service for your Experience Server:
- Open the command line interface and navigate to the [ExperienceServer root]/opt/helpers/ directory.
- Execute the
instsrv.bat <serviceName>command to install the Experience Server as a Windows service.
Verify the installed Windows service
You can verify the installed Windows service in the Services control panel. To open the Services control panel, execute the
start services.msc command from the command line interface or select Start > Administrative Tools > Services.
Windows service operations
To start the Windows service, do one of the following:
- In the Services control panel, select the Windows service and click Start.
- In the command line interface, execute the
net start <serviceName>command.
To stop or restart the Windows service for the Experience Server, click Stop or Restart, on the Services control panel.
Uninstall the Windows service
To uninstall the Windows service, execute the
instsrv.bat -uninstall <serviceName> command on the command line interface. The Windows service gets removed from the Services control panel.
Original article at http://blogs.adobe.com/ADEPhelp/2011/09/installing-windows-service-for-adep-experience-server.html.
If you try to render an XFA form as HTML, chances are that you will encounter the following error: ERROR [com.adobe.livecycle.formsservice.exception.FormServerException] (http-0.0.0.0-8080-97) ALC-FRM-001-006: URI not found: /scripts/xfasubset.js Cause: scriptsxfasubset.js (The system cannot find the path specified) xfasubset.js is a BLOB … Continue reading →
Original article at http://blogs.adobe.com/ADEP/2011/09/how-to-avoid-missing-xfasubset-js-error-in-adep-forms.html.
It’s not a secret feature in CQ/WEM/DAM, but it’s still comparatively unknown – the HTML5-based file upload capability. Editing content is so much more fun if you don’t have to open a dialog [click], navigate through your folder structure [click][click][click] … Continue reading →
Original article at http://blogs.adobe.com/ADEP/2011/09/html5-file-upload-in-wem.html.
The Adobe Customer Experience solution “Customer Communications – Interactive Statements” (formerly Interactive Statements Solution Accelerator) requires an XA-type JDBC data source. If the RDBMS being used is Oracle 11g, the user that connects to Oracle on behalf of the J2EE appserver JDBC connection pool requires additional “object privileges” to certain SYSTEM tables in Oracle. Essentially, these are as follows:
- SELECT object privileges on tables sys.dba_pending_transactions, sys.pending_trans$ and sys.dba_2pc_pending
- EXECUTE object privileges on table sys.dbms_xa
The required DDL is available in the ADEP install documentation here.
If this is not done, you will get WARNING messages in your appserver log that looks something like this:
WARN [loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery got XA exception javax.transacti
See here for SQL Server 2008.
Original article at http://blogs.adobe.com/ADEP/2011/08/enabling-xa-transactions-in-oracle-11g-for-adep-interactive-statements.html.
LiveCycle product blog has recently published a nice article that allows you to check if the LiveCycle scheduler has started properly in cluster mode or not.
Thanks LiveCycle team for publishing the details.
The blog entry can be found at – http://blogs.adobe.com/livecycle/2011/02/schedulerclustermode.html
Original article at http://blog.pandyaparth.com/2011/02/determining-if-the-livecycle-scheduler-has-started-in-cluster-mode/.
If you want to seriously geek out on this and try it, you can download LiveCycle ES from http://www.adobe.com/products/livecycle/.
Original article at http://technoracle.blogspot.com/2011/02/build-livecycle-encryption-process.html.