Posts in Category "Workbench"

Dymystifying application configuration for LiveCycle Workspace ES

Creating human-centric processes for LiveCycle Workspace ES can be tricky when you want to include operations from Signatures, Encryption, Rights Management, and Reader Extensions services in your process. There are a few technology nuances that can make it seem more difficult to configure human-centric applications than it should be. New to our LiveCycle ES 8.2 documentation set, is a guide on helping experienced developers understand recommended techniques for creating human-centric processes. These techniques include best practices, tips, and references to existing LiveCycle ES documentation. This new guide, Techniques for Configuring Applications for LiveCycle Workspace ES, can help you to design processes to meet your business requirements and provide an optimal experience for your Workspace ES users.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

Using process variables as constants

A common pattern that’s used in process design is establishing ‘constant’ values that you refer to a few times in the process. To establish a constant value, you either:

  • Create the variable and configure the default value at design time (i.e. in Workbench ES), or
  • Save a value that is either passed into the process or returned by a service operation at run time.

    Continue reading…

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

Retrieving notes from tasks

You know those notes that can be added to tasks using Workspace ES? (If you don’t, you can take a look at Working with notes and attachments). The Workbench ES help explains how to retrieve those notes as a document value after the form is submitted, but (believe it or not) the help leaves out a few details about how to reference the information in those notes.

Continue reading…

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

Tips for maximizing Output service performance

Here are a few easy ways to improve performance when using the Output service with forms.

Continue reading…

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

The Basics of Form Guides

What is a form guide?

A form guide is a wizard based in Adobe Flash that you can create as an alternative method for your users to enter data onto your form. A user is literally guided through the data entry process, which helps to reduce entry errors by limiting the amount of information presented to the user at any given moment. So instead of seeing a mass of fields and text – because the powers that be demand that you cram as much as possible onto that one sheet of 8.5” x 11” – the user sees chunks of information with animated transitions to move them from one chunk to another. It makes filling out forms feel less like, well, filling out forms.

Click here to see what a form guide looks like.

Note: To view form guides you must have Adobe Flash Player 9 or later installed.

Why would I want to use a form guide?

There are lots of reasons why you might want to use form guides, but here’s an example modeled on a real world case. The following image is of an immunization form.

immunization.png


To see a larger image, click
View image

The requirements of the form stipulated that users can print and fold it into a booklet in which medical staff could then manually write records of immunizations for a particular patient. Somewhere along the way someone decided it might be nice to also make the same form available in electronic format, but the user should print and fold the form after entering the data. Given this situation, you could create two separate forms, or you could go 21st century and make a form guide. The image below shows the form guide created for the immunization form. As you can see it’s a lot nicer than having to rotate your head ninety degrees every so often.

immunization_swf.png


View image

How do you create form guides?

You create form guides using Guide Builder, a tool available in LiveCycle Designer ES. As it turns out this is a handy arrangement because you create form guides from form designs, which are also created in LiveCycle Designer ES. Once you create a form guide for a particular form design, the form guide definition is actually saved inside the form design itself.

If you want to view a form guide as if you were the user doing the data entry, you can preview it right in Guide Builder. However, when you want to actually deploy a form guide to users, you will need to either:

  • Create a process design in Workbench ES that renders a form guide to Workspace ES. Your users then access the form guide through Workspace ES.
  • Render the form guide from a Java or web services applications using the LiveCycle Forms ES service to render the form guide. Your users access the form guide using the Java or web services application.

Read More

You can find a bunch of information about form guides in our product documentation. Check out the links below:

Have fun creating your own form guides. Drop us a note to tell us about your experiences.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

LiveCycle Workspace ES in a nutshell…

Did you know that you can use LiveCycle Workspace ES to interact with processes that involve users set in LiveCycle ES? Workspace ES is an RIA (Rich Internet Application) that comes with Process Management ES and allows end users to participate in and start processes that you developed. They can also search for processes using provided search templates and see custom messages in the Workspace ES banner. The search templates and banner messages are set by you as the Workspace ES administrator.

For example, Tony Blue, who is a client of Insur@nce Corp, needs to submit an insurance claim. The insurance claim he submits in Workspace ES automatically gets routed to insurance agents at an insurance company. The application form might be provided as a form guide, which is a Flash-based form that provides an easier experience for filling out the details. After the form is completed and submitted, it gets routed to the agents, where the form might be displayed as a PDF. There can be business logic set in the process so that certain types of applications are routed to different insurance agents. Since there can be many agents at the insurance company, who can get hundreds of applications a day, their list of applications to review can be managed using individual or team queues. Workspace ES also allows the agents to share their queue with each other to balance the workload or re-route applications when they are out of the office. Below is what Tony sees when he fills out his claim:

WorkspaceFGClaimForm.jpg
To see a larger image, click here

Before automating your business process for use in Workspace ES, you must design a form and a process In LiveCycle Designer ES, you design the form, which displays and captures information from users involved in the process. The form can be displayed in PDF, HTML, or as a form guide. You can also design the form in Flex Builder or the Flex SDK. Flex forms can provide an enriched experience that transcends traditional forms designed in Designer ES. In LiveCycle Workbench ES, you design the process map, which is a graphical representation of your business process. You can configure the process map with business rules, inputs, and outputs.

After designing your form and process map, you configure your automated business process for use in the LiveCycle Administration Console by setting the process to be started from Workspace ES.

Since Workspace ES comes out-of-the-box, you may want to customize it for your organization. You can rebrand it with your own colors and images or you can build your own RIA using pieces of the Workspace ES User interface and components from the Workspace ES API.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 8.0/10 (1 vote cast)

Correction for Workbench ES Help: Multiple instances synchronization

A user contacted me recently with a question about the “Multiple instances synchronization” process modeling example in the Workbench ES Help. I realized that a mistake in the process diagrams had caused the confusion (Sorry Lachlan, and thanks again for pointing it out).

The example shows how to converge a number of process branches or subprocesses that are executing independently. This scenario is useful if you want your main process to execute the same subprocess or branch multiple times, and then continue only after all of the instances of the subprocess are complete.

To converge the instances, each one throws an event that the main process receives. A loop is used to count the number of events that are received. The loop executes until the number of received events equals the number of instances that were executed.

The problem with the diagrams for the Multiple instances synchronization example is that they did not include the loop (my bad). Below are the diagrams with the loop included.

Gateway implementation (click to see larger image)
gateway.gif
Events implementation (click to see larger image)
event.gif

Resources
For more modeling examples, such as Multiple independent instances, see Process diagram modeling examples.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

Execution contexts and LiveCycle ES processes

Recently, I’ve learned more about execution contexts for process services and thought it might be important enough to post here.

Execution contexts determine which user’s account credentials are used to execute a service. Recall that a service is created for all processes that are activated, and each operation in a process is also provided by a service. So, all processes and operations have an execution context.

A few changes were implemented in LiveCycle ES Update 1 (that’s version 8.2.1) that changed the way execution contexts work for processes. For both versions, the user that invokes the process is used as the invocation context for executing the process. The difference is in what invocation context is used for executing the operations in the process.

In LiveCycle ES (that’s version 8.0.x), the context that is used for process operations depends on whether the process is long-lived or short-lived:
• In short-lived processes, the context of the user who invoked the process is used to execute each operation in the process.
• In long-lived processes, the System user (similar to a super administrator) is used to execute each operation in the process.

In LiveCycle ES Update 1, you can use Adobe Administration Console to specify a user account to use for executing process operations. Also, the behavior is the same for long-lived and short-lived processes. There are three options for configuring this feature:
• Run-As Invoker (the default): The context of the user account that invoked the process is used to invoke the operations in the process.
• Run-As system: The System user executes the operations.
• Run-as named user: A user account that you specify is used to execute the operations.

To learn more about configuring this feature, read Modifying security settings in Applications and Services Administration Help.

Note that for both releases of LiveCycle ES, render and submit services that are used with xfaForm, Document Form, and Form variables are always executed using the System user account.

Why is this important?

For some services, the user account that executes the operation affects the results. For example, in Content Services ES, the user that stores content is made the owner of the content, which affects who can later access the content. If you are using a process to store content, you need to think about what user is used to execute the Document Management service, because that user will own the stored content.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

How to generate an XML schema for an existing form

Until recently, when I’ve been using LiveCycle ES to learn about developing processes I often found myself creating a form using Designer ES and manually creating an XML schema to embed in it. I want to embed the schema so that I can see the data model of the form in Workbench ES. Seeing the data model is useful when you are creating XPath expressions using XPath Builder to access a value from the form data.

My limited knowledge of XML schema enables me to create only the simplest of schemas, and consequently, the simplest of forms. However, I’ve now learned how to generate an XML schema for an existing form. This frees me from having to learn the intricacies of XML schema, and enables me to use more complex forms in my processes:

1. Create the form in Designer ES. If you are creating an XDP file, save it as a different file in PDF format.
2. Open the form in Acrobat Professional.
3. Save the form data to an XML file.
4. Use the file with a tool that derives XML schemas from XML documents.
5. Embed the schema in the form. (see Displaying the form data model in XPath Builder in LiveCycle Workbench ES Help.)

Here is a blog article that lists a few free tools that derive schemas from XML: http://blog.dotkam.com/2008/05/28/generate-xsd-from-xml/. I like using Trang, a command-line tool written in Java (you need to have a Java runtime environment (JRE) installed to run it). The blog also lists some GUI-based tools if you prefer those.

Further Considerations

You may be tempted to use the XML schema that you generate as the schema for a database to use to store form data. This would work, however this solution doesn’t scale well. If you develop several LiveCycle ES applications you will likely use many different forms to gather different sets of data. In this case, you should use a common schema for all forms.

It’s also important to realize that the process doesn’t need the XML schema to execute correctly. XPath expressions that locate form field data items are evaluated correctly regardless of whether the schema is present. You also don’t need to see the data model of the form in XPath builder to create XPath expressions. Seeing the data model makes it much easier.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 3.7/10 (3 votes cast)

Debugging Processes in LiveCycle Workbench ES – Record and Playback

Have you ever had a less than ideal experience debugging a process using LiveCycle Workbench ES? In previous versions , the only way to debug your processes was to monitor the server logs or use the Variable Logger service. These methods allowed you to see variable values and also monitor how your process progressed, but they did not visually allow you correlate the data for effective debugging and troubleshooting.

New to Workbench ES in LiveCycle ES Update 1 (8.2) is the ability to record your processes as they run and then play them back to ease your debugging experience. These new record and playback features allow you to visually step through the progression of a process (both the steps and routes taken), view variable values, and see specific errors related to issues in a process.

The recordings are saved on the LiveCycle ES server, where other developers using Workbench ES can also access recordings, allowing for collaboration and efficiencies when debugging or troubleshooting processes. Since recording and playing back processes can degrade the server performance, we recommend only using this feature in development or testing environments – not production environments. You can delete recordings when you no longer require them and when you are done debugging a process, you can disable the recording.

For more information about using the new Record and Playback feature, see http://www.adobe.com/go/learn_lc_workbench_82?context=Workbench_ES&topic=000271.

The following illustrates a process version in Playback mode:

recordPlaybackWB.jpg

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)