Posts tagged Workbench

Tutorial to use the Execute Script service in Adobe LiveCycle Workbench ES2

- Gilbert Yu

Would you like to learn how to use the Execute Script service to manipulate XML using LiveCycle Workbench ES2? Here is a tutorial provided by one of our Adobe partners, Twin Technologies!

Check out the most excellent tutorial from Deke Smith at here.

——-
Original article at http://blogs.adobe.com/ADEPhelp/2011/05/tutorial-to-use-the-execute-script-service-in-livecycle-workbench-es2.html.

Workspace Common Variables

Would you like your Workspace users to be able to see all process instances or tasks related to a particular customer name that they participated in? Would you like to refine the number of items displayed in your To Do or Tracking lists based on a particular value?

ADEP Process Management 10.0 has introduced a new feature called Common Variables which will allow you to do this. The overall purpose of this feature is to enhance the Workspace UI experience by allowing users to see and filter on information that is common across all processes.

In three easy steps, you can be using this new feature.

  1. Create the variables in a system application in Workbench.
  2. Set them in your process using a Set Value service.
  3. View them in Workspace, as values in a Search Template or as column headings.

Note: This feature is intended to be used with simple variable types only such as string, boolean, date, date-time, int, long and short. Only simple types will display in Workspace.

1) Create your Variables in Workbench

You will define your common variables in a new system application called Process Manager (common-variables).

  1. Do a File->Get Application in Workbench to download the process.
  2. Check out the CommonVariables process.
  3. Add  a variable in the usual way.
  4. Save the process and Deploy the application.

In the screenshot below, I have added a string variable called custName with a Title of “Customer Name.” The title is what users will see in Workspace.

Note that by default, the variable is marked “Searchable” and “Visible in UI”. Searchable allows you to add the variable to a search template and Visible in UI allows the variable to be exposed as a column heading. Also, since this is a common variable, the ability to mark it as Input/Output/Required has been removed.

 

2) Set Common Variables in your Process in Workbench

Now that you have created your variable, it will be available to all processes. You just need to set it in whichever process you want to use it in. The contents of these variables at runtime will be unique per process instance, just like any other process variable.

To set your common variable, you will use the XPath builder in the Set Value service. In the screenshot below, you will note that in addition to the Process Data node there is now a Common Data node to display common variables.

In my example, I have a field in my form named OrderedByCompany. The Workspace user will fill in this field before submitting the form. I will then take this value out of my form data (I picked this “Expression” from the Process Data node in the XPath builder) and map it into my common variable called custName (I picked this “Location” from the Common Data node).

When the process is run, these values will be set in the same way as normal process variables.

 

3) Viewing your Common Variables in Workspace

Now that your process has been run and the common variable has been set, there are multiple ways that you can see the common variable values in Workspace. They will appear as column headings in To Do and Tracking and as values returned in a Search.

Column Headings – To Do

Another new feature that was added in ADEP Process Management 10.0 is the ability to set your column preferences directly on the page you are working on. This applies to To Do and Tracking. You will use this feature to see the value of your common variables in Workspace.

Navigate to To Do. Select your queue, and make sure that you are in List View. Select the Manage Column Headings button in the top-right. Select your common variable from the list (mine was Customer Name) and select OK.

Your common variable will now appear as a column….with the values that were set when the process was run. Note that my queue in the screenshot below is set to “Show All” processes…I don’t have to select a specific process to see common variables. Since they appear across all processes, this may help to refine your To Do list.

Below, you will see that Maple Trust appears three times, once for the PurchaseOrder process and twice for the MortgageApplicationStart process.

If I filter on “Maple”, my list below will show three tasks from different processes that have the Maple Trust customer name in common. This has filtered the other 6 tasks from my list.  (Note that clearing the filter brings back the other 6 tasks.)

 

Column Headings – Tracking

The ability to see common variables also applies to Tracking. This may provide more context when looking for a particular process instance. You can filter on the variables in the same way that I detailed above in the To Do page.

 

Values From a Search

Common variables may also be used in a Search Template. Using my example, this will allow a user to search for a particular customer name across different processes and will show them the tasks that they have participated in.

The ADEP administrator will create a Search Template that contains the common variable. When they create the template, the common variables will appear automatically under the Process Variables section. (For regular process variables you first have to select the process where they are defined. Common variables do not require this extra step.)

In my example, my Search Template asks the user to provide a Customer Name.

I entered Maple Trust and all tasks with Customer name Maple Trust are returned.  In my case there were two processes that used this common variable and search results were returned for both processes.

 

Common Variables Best Practices

  • When you are ready to move your Process Manager (common-variables) application from development to production via an lca, make sure you don’t change the application name and process name. The common variables feature depends on this application name/process name being Process Manager (common-variables)/CommonVariables.
  • Do not create complex variable types (lists, maps etc) for use as common variables. Although Workbench allows you to do this, the feature was intended to be used with simple types only. Only simple types will display in Workspace.
  • Limit the number of common variables in your system to reduce possible performance implications.
  • It is not recommended to version the Process Manager (common-variables) process.
  • Only delete a common variable from the CommonVariables process if you are sure it is not referenced in any process. As with regular process variables, referencing a deleted variable will cause your process instance to stall.  If you are unsure whether it is referenced, a better practice would be to uncheck the “Visible in UI” and “Searchable” properties on the variable. This means the variable will no longer display in Workspace or be available for Searching.
  • Default values can be used in common variables.  Unless you override it in a SetValue service, the default value will be used.
  • The CommonVariables process is a system process. Use it only to define your variables. Do not add any steps to it, invoke it or reference it as a sub-process.

Additional Information

  • Record & Playback is currently not supported for common variables.

——-
Original article at http://blogs.adobe.com/ADEP/2011/08/workspace-common-variables.html.

Stopping Duplicate Attachments in Workspace


When using the attachments feature on the User service, you may have encountered a situation where attachments are being duplicated at each step of the process. This will happen whether you reference the “list of document” variable itself or the XPath expression of the variable.

The way to get around this issue is to reference the XPath expression of the variable and append [1] to it.


In Workbench, navigate to the Attachments tab of the User service.
In the Output Attachments section, make sure that the dropdown is set to XPath expression.
Select your variable of type list of document and append [1] to it.
It should now appear as /process_data/myAttachments[1].

Attachments tab on the User serviceAttachments tab on the User service

Make sure you use this same notation (/process_data/myAttachments[1]) on each User service step.

——-
Original article at http://blogs.adobe.com/ADEP/2011/08/stopping-duplicate-attachments-in-workspace.html.

How to Invoke LiveCycle Forms from an Existing XDP Form in Acrobat/Reader or Browser Plugin and Get Another Form Rendered Back to the Client

Lately I have had a request from a customer of mine who wanted to modify existing XDP forms (ie. change a label or a field value) on the fly without going in LiveCycle Designer (ie. the procedure would imply costs for hiring the dev department).

His idea was to have a Form A, in which he would be able to specify the changes he desires to have in the Form B, submit the form  A to a LC orchestration which would apply the changes and render the Form B back in Acrobat/Reader or even the browser plugin.

Here I am only covering the call to LC and the rendering back to the client.

Note: I am using LCES 2 SP2 (9.0.0.2) running on Jboss.

So we have Form A that could look like this:

Note: i will explain the submit URL later on.

As we can see we have a few fields that would mean something to Form B and as an end user we will open Form A in Acrobat/ Reader or even the browser plugin to enter the value we want to see in Form B.

We need to go in LC Workbench to create an orchestration which will render Form B:

We can see I used the RenderPDFForm service operation and created a variable (type document) for the input Form and to make things simple I had put Form B in the application  structure:


The key element for the invocation of the orchestration from Form A is to rely on the REST protocol (http post):

We can find the right URL for the call by selecting the Default startpoint properties:

Since I going to run the test on the same machine where Livecycle is running the URL looks like this:

http://localhost:8080/rest/services/test/renderForm:1.0

Note: “test” is the name of my application  and “renderForm” is my process (orchestration) and 1.0 is its version.

This is the URL I put in the submit button in Form A (see first screenshot).

In order to make the call successful, we need to create variables to match the fields in Form A: Name, FormContent and MainParagraph.

Of course, in the scenario where you want to modify Form B with Form A fields values, you would need those variables to apply the desired changes.

Note: by matching i meant the variables name and type (most of the time it would be string but you can have list as well).

Here I am only rendering the Form B without any changes so I did not bother adding more activities in my orchestration which would utilise those variables.

Once the orchestration and the forms have been saved and the application deployed on the server, all we need is to open Form A in the client of our choice, here I used Internet Explorer so we can see the URL at the top.

I click on the button “open form via REST” and the login request pops up and i use my LC credentials to access:

Once logged in Form B is appearing in the same window:

Note: When using Reader or Acrobat, it will open a new window for Form B.

No need to Reader Extend Form A to make it work hence it works in Reader standalone and plugin.

——-
Original article at http://blogs.adobe.com/ADEP/2011/08/invoke_forms_from_xdp.html.

Workspace Common Variables

Would you like your Workspace users to be able to see all process instances or tasks related to a particular customer name that they participated in? Would you like to refine the number of items displayed in your To Do or Tracking lists based on a particular value?

ADEP Process Management 10.0 has introduced a new feature called Common Variables which will allow you to do this. The overall purpose of this feature is to enhance the Workspace UI experience by allowing users to see and filter on information that is common across all processes.

In three easy steps, you can be using this new feature.

  1. Create the variables in a system application in Workbench.
  2. Set them in your process using a Set Value service.
  3. View them in Workspace, as values in a Search Template or as column headings.

Note: This feature is intended to be used with simple variable types only such as string, boolean, date, date-time, int, long and short. Only simple types will display in Workspace.

1) Create your Variables in Workbench

You will define your common variables in a new system application called Process Manager (common-variables).

  1. Do a File->Get Application in Workbench to download the process.
  2. Check out the CommonVariables process.
  3. Add  a variable in the usual way.
  4. Save the process and Deploy the application.

In the screenshot below, I have added a string variable called custName with a Title of “Customer Name.” The title is what users will see in Workspace.

Note that by default, the variable is marked “Searchable” and “Visible in UI”. Searchable allows you to add the variable to a search template and Visible in UI allows the variable to be exposed as a column heading. Also, since this is a common variable, the ability to mark it as Input/Output/Required has been removed.

 

2) Set Common Variables in your Process in Workbench

Now that you have created your variable, it will be available to all processes. You just need to set it in whichever process you want to use it in. The contents of these variables at runtime will be unique per process instance, just like any other process variable.

To set your common variable, you will use the XPath builder in the Set Value service. In the screenshot below, you will note that in addition to the Process Data node there is now a Common Data node to display common variables.

In my example, I have a field in my form named OrderedByCompany. The Workspace user will fill in this field before submitting the form. I will then take this value out of my form data (I picked this “Expression” from the Process Data node in the XPath builder) and map it into my common variable called custName (I picked this “Location” from the Common Data node).

When the process is run, these values will be set in the same way as normal process variables.

 

3) Viewing your Common Variables in Workspace

Now that your process has been run and the common variable has been set, there are multiple ways that you can see the common variable values in Workspace. They will appear as column headings in To Do and Tracking and as values returned in a Search.

Column Headings – To Do

Another new feature that was added in ADEP Process Management 10.0 is the ability to set your column preferences directly on the page you are working on. This applies to To Do and Tracking. You will use this feature to see the value of your common variables in Workspace.

Navigate to To Do. Select your queue, and make sure that you are in List View. Select the Manage Column Headings button in the top-right. Select your common variable from the list (mine was Customer Name) and select OK.

Your common variable will now appear as a column….with the values that were set when the process was run. Note that my queue in the screenshot below is set to “Show All” processes…I don’t have to select a specific process to see common variables. Since they appear across all processes, this may help to refine your To Do list.

Below, you will see that Maple Trust appears three times, once for the PurchaseOrder process and twice for the MortgageApplicationStart process.

If I filter on “Maple”, my list below will show three tasks from different processes that have the Maple Trust customer name in common. This has filtered the other 6 tasks from my list.  (Note that clearing the filter brings back the other 6 tasks.)

 

Column Headings – Tracking

The ability to see common variables also applies to Tracking. This may provide more context when looking for a particular process instance. You can filter on the variables in the same way that I detailed above in the To Do page.

 

Values From a Search

Common variables may also be used in a Search Template. Using my example, this will allow a user to search for a particular customer name across different processes and will show them the tasks that they have participated in.

The ADEP administrator will create a Search Template that contains the common variable. When they create the template, the common variables will appear automatically under the Process Variables section. (For regular process variables you first have to select the process where they are defined. Common variables do not require this extra step.)

In my example, my Search Template asks the user to provide a Customer Name.

I entered Maple Trust and all tasks with Customer name Maple Trust are returned.  In my case there were two processes that used this common variable and search results were returned for both processes.

 

Common Variables Best Practices

  • When you are ready to move your Process Manager (common-variables) application from development to production via an lca, make sure you don’t change the application name and process name. The common variables feature depends on this application name/process name being Process Manager (common-variables)/CommonVariables.
  • Do not create complex variable types (lists, maps etc) for use as common variables. Although Workbench allows you to do this, the feature was intended to be used with simple types only. Only simple types will display in Workspace.
  • Limit the number of common variables in your system to reduce possible performance implications.
  • It is not recommended to version the Process Manager (common-variables) process.
  • Only delete a common variable from the CommonVariables process if you are sure it is not referenced in any process. As with regular process variables, referencing a deleted variable will cause your process instance to stall.  If you are unsure whether it is referenced, a better practice would be to uncheck the “Visible in UI” and “Searchable” properties on the variable. This means the variable will no longer display in Workspace or be available for Searching.
  • Default values can be used in common variables.  Unless you override it in a SetValue service, the default value will be used.
  • The CommonVariables process is a system process. Use it only to define your variables. Do not add any steps to it, invoke it or reference it as a sub-process.

Additional Information

  • Record & Playback is currently not supported for common variables.

——-
Original article at http://blogs.adobe.com/ADEP/2011/08/workspace-common-variables.html.

Configuring Limits For LiveCycle Workbench Recordings

Chris Trubiani

I learned something new today and figured it was worth sharing for other people that didn’t realize these settings existed.  On a call I was asked why recordings of a process would stop after a certain number of steps and how that can be configured.  Honestly, I didn’t even realize we limited this, though now that I do it does make sense as a good idea to avoid having recordings take up a massive amount of disk space.  So I took the question offline and dug into it.

It turns out there are two configuration parameters to set limits for recordings done in Workbench.  The setting can be found and configured in Adminui under Services->Applications and Services->Service Management.  Select the AuditWorkflowService service, and then click the Configuration tab.  The two settings are:

  1. maxNumberOfRecordingInstances – This is the maximum total number of recorded processes that will be allowed on the server at any time.  By default the value is 50.  When you go to record the 51st process the 1st process recording will be deleted from the server to make room for the new one.
  2. maxNumberOfRecordingEntries – This is the maximum total number of steps in a process that will be saved in a recording.  By default the value is 50.  If a process being recorded consists of 75 steps, then the first until the 50th step will be saved into the recording.  Steps 51 to 75 will not be saved.

The first parameter is nice to know about, but I think in most cases having a history of 50 process recordings will be sufficient.  It’s the second parameter that is most likely to cause problems for people when trying to debug large processes.  To that end if you see the following warning in your server’s log file you’ll now know that your running into this limit and need to change the value accordingly:

WARNING: stop recording entries due to space limitation.

——-
Original article at http://blogs.adobe.com/livecycle/2011/04/recording-limits.html.

LiveCycle ES2 Guides – Adding custom validation classes to your model

- Waldo Smeets

The Modeler in LiveCycle ES2 ships with several built-in validation classes, which you can apply to the models properties using the Styles definition. Obviously these standard classes don’t cover all use cases, especially not validation behavior that is specific to a non-US region for example. One of the cool things about Fiber models is that you can extend them using custom ActionScript code, so that you can use your custom validation classes in your projects (I plan to write another article on working with custom methods in your model by overwriting the generated value objects).

So, you can add and apply your own validation classes to the model. You just need to refer to your custom class in the Style validation annotation of the property. First, copy the validation class itself into the correct folder of your Workbench project. That’s also the trickiest part within the LiveCycle Modeler (compared to doing this for the Flash Builder modeler). The FB modeler generates the code into your Flex project folder and you can easily find it, but Workbench doesn’t generate the code in the directory where all your other projects are located (on Vista/Win7 that is C:UsersusernameWorkbench ES2). I am not exactly sure why, but I think because the model generated classes are mostly temp files that don’t have to be checked into the server (downside is that you need to backup modifications of custom classes yourself).

That ‘temp’ folder that stores all model generated classes is much deeper on your disk drive. On my system it’s C:UsersusernameAppDataRoamingAdobeLiveCycleES2Guidesgenerated. Here you find subfolders structured per LiveCycle application. For your project, find the folder where the generated myModel.as and myModel.swf files are located. Consider this folder the ‘root’ that is used by the compiler, so this is where yoy copy your custom validator classes to.

The last step is to define the style validation annotations within the property. Basically you’d define your property like this:

<property type=”string”>
<style>
<validation>
<annotation name=”ActionScriptValidator”>
<item name=”ValidatorClass”>mx.validators.SocialSecurityValidator</item>
<item name=”allowedFormatChars”>”-()”</item>
</annotation>
</validation>
</style>
</property>

The ValidatorClass item defines the class path, and in this case the ‘allowedFormatChars’ is one of the parameters that is used by that class. Now make sure that Workbench recompiles your class (just move an entity a few pixels, save and the recompile will hapen). Now your custom validator class is compiled into the model itself and you are ready to use the related properties within your guide!

ps: Workbench will inform you on compilation errors if you made errors in your class.

—-
Original article at http://www.drflex.eu/2010/03/livecycle-es2-guides-adding-custom-validation-classes-to-your-model/.

Using Namespace in Workbench

Girish Bedekar

The xml returned by webservices invariably use namespaces. To access data contained in the xml you would need to declare namespace . To declare namespace you would select the process,right click the process select properties, click the advanced tab to create namespaces
For example the following is a example of namespace declared in workbench
greg http://schemas.xmlsoap.org/soap/envelope/
where greg is the namespace prefix
I have included a simple process which makes a web service call to Amazon, using namespace I get data out of the response. The following is an example of using namespace in workbench
/process_data/xmlData/greg:Envelope/greg:Body/cole:ItemLookupResponse/cole:Items/cole:Item/cole:ItemAttributes
Click here to get the PDF

—-
Original article at http://eslifeline.wordpress.com/2009/02/06/using-namespace-in-workbench/.

Emailing to all members of a group

Girish Bedekar

I have written a simple process which lets you email to all members of a group
This process takes in the name of a group as input parameter and emails to all members of the group
Before invoking the process make sure you have set the configuration settings of the email component(the last step of the process)
Click here to get the pdf file which has the process
Click here to get the pdf
Let me know if you have any further questions
thanks
girish

—-
Original article at http://eslifeline.wordpress.com/2009/02/10/emailing-to-all-members-of-a-group/.

Accessing MS-Office (custom) properties from LiveCycle ES processes

- Marcel Van Espen

You probably know the case, you want to convert a file to PDF and add a fax page so you can send it to a customer using your fax-server, or you just want to add a coverpage so you can archive the file in a effective way and have all the metadata nicely grouped on that coverpage.

There are simple ways to let LiveCycle ES take care of that process for you. Below a short explanation of some of the available services that are relevant in this context.

Within LiveCycle Workbench ES, one of the services in the common category that you can use is “Export XMP“. This service will extract all the available metadata from a PDF document. If you have converted a MS-Office document to a PDF document, you will be surprised what metadata is also converted. All these properties are now accessible using the service above. Here is a screenshot of some custom properties in a Word document.

Result of the Export XMP service is an XML structure that you can query. For instance, if you want to know what’s in some of the custom metadata fields, you can check this file. Here is a sample of the result of an Export XMP service.

<?xpacket begin=”” id=”W5M0MpCehiHzreSzNTczkc9d”?>
<x:xmpmeta xmlns:x=”adobe:ns:meta/” x:xmptk=”Adobe XMP Core 4.2-jc015 52.349034, 2008 Jun 20 00:30:39-PDT (debug)”>
<rdf:RDF xmlns:rdf=”
http://www.w3.org/1999/02/22-rdf-syntax-ns#”>
<rdf:Description rdf:about=””
xmlns:xmp=”
http://ns.adobe.com/xap/1.0/“>
<xmp:CreateDate>2008-12-23T09:45:28+01:00</xmp:CreateDate>
<xmp:CreatorTool>Acrobat PDFMaker 9.0 for Word</xmp:CreatorTool>
<xmp:ModifyDate>2008-12-23T09:45:28+01:00</xmp:ModifyDate>
<xmp:MetadataDate>2008-12-23T09:45:28+01:00</xmp:MetadataDate>
</rdf:Description>
<rdf:Description rdf:about=””
xmlns:pdf=”
http://ns.adobe.com/pdf/1.3/“>
<pdf:Producer>Acrobat Distiller 9.0.0 (Windows)</pdf:Producer>
<pdf:Keywords>”PDF, Metadata”</pdf:Keywords>
</rdf:Description>
<rdf:Description rdf:about=””
xmlns:dc=”
http://purl.org/dc/elements/1.1/“>
<dc:format>application/pdf</dc:format>
<dc:creator>
<rdf:Seq>
<rdf:li>Marcel van Espen</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:title>
<rdf:Alt>
<rdf:li xml:lang=”x-default”>This is a test document</rdf:li>
</rdf:Alt>
</dc:title>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang=”x-default”>Onderwerp</rdf:li>
</rdf:Alt>
</dc:description>
<dc:subject>
<rdf:Bag>
<rdf:li>PDF, Metadata</rdf:li>
</rdf:Bag>
</dc:subject>
</rdf:Description>
<rdf:Description rdf:about=””
xmlns:pdfx=”
http://ns.adobe.com/pdfx/1.3/“>
<pdfx:Company>Adobe Systems Incorporated</pdfx:Company>
<pdfx:Department>Development</pdfx:Department>
<pdfx:Language>English</pdfx:Language>
<pdfx:Office>Amsterdam</pdfx:Office>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end=”w”?>

Now, you will see some familiar tags in there. If you would like to access the custom property Office (With value Amsterdam) as highlighted in bold above, you will need to do the following:

  1. Store the result data from the Export XMP service in a variable of type XML (for this example this will be xmpdocxml)
  2. Create a variable of type string (In this case it will be office) to store the office location (of course you can also put it in a form template, but this is out of scope for this example)
  3. Use a set value service to set /process_data/@Office = /process_data/xmpdocxml/x:xmpmeta/rdf:RDF/rdf:Description/pdfx:Office

That’s it. You can of course repeat this for all the other elements, and do what you like with it. I have created a simple example and made it available on acrobat.com. In the sample (zip file) I included a LiveCycle LCA file that you can import, a sample Word document and an XML file that is just showing you the metadata.

If this is too much for you, there is an even simpler service to retrieve the metadata from a document. This service, Export Metadata, gives you a nice XML structure that you can browse using your XPATH editor. Note that this only retrieves the basic metadata!

—-
Original article at http://www.drflex.eu/2008/12/accessing-ms-office-custom-properties-from-livecycle-es-processes/.

Go to Top