Posts tagged workspace

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.

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.

Manage Column Headings in Workspace just got easier

ADEP Workspace has introduced a new feature that allows you to manage your column headings without having to pop back and forth to the Preferences page. Column headings can now be managed directly from the page that is displaying the columns. This new ‘in situ’ feature can be accessed via List View on the To Do, Tracking and History tabs.

Modifying column headings on To Do:

  • Set your To Do display to List View
  • Click the Manage Column Headings button

You should then be presented with the Manage Column Headings pop-up panel:

At this point you can select any column heading and enable or disable the column as well as change the column location by moving the column heading up or down the column list.  The changes you make here are persisted as part of your Workspace preferences so the changes you make will be displayed the next time you log in to Workspace.

Note that the Manage Column Headings will also display Common Process Variables as well as process specific variables.  To view the process specific variables you must be viewing process instances for a particular process rather than the ‘Show All’ view of your To Do list.

Modifying column headings on Tracking:

ADEP Workspace now allows you to manage the high level Tracking columns (previous releases had fixed columns until you drilled into a process instance). ADEP Workspace also allows you to display Common Process Variables as well as process specific variables on the Tracking page to make it easier to find the task you are looking for.

In the above example I have exposed the Mortgage Amount process variable.  I am now able to locate the process instance for the $350,000 mortgage application without having to open each process instance in order to find that particular mortgage application.

——-
Original article at http://blogs.adobe.com/ADEP/2011/08/manage-column-headings-in-workspace-just-got-easier.html.

Extracting Data from Signed PDF using LiveCycle Server

Girish Bedekar

Very common request- how do I extract data from a Signed PDF using livecycle ES
To do this you will need to have livecycle server software installed. This example uses processFormSubmission service operation of the forms component.
Attached is the PDF which explains the process and it also has the process lca and the test file need to run the process
Click here
This process can be used when you are getting the signed PDF from email/watchedFolder. This process can also be used when you are submitting the signed pdf from workspace

—-
Original article at http://eslifeline.wordpress.com/2009/04/25/extracting-data-from-signed-pdf-using-livecycle-server/.

JGroups and LiveCycle Workspace – Explained

Darren Melanson

First, an elementary explanation of what it is: JGroups is a toolkit that is used in LiveCycle to broadcast group based messages in a controlled infrastructure which by default leverages multicast as a communication mechanism. A much more defined and thorough explanation can be found at jgroups.org. This post is intended to provide some insight into how JGroups is used in LiveCycle ES and ES2 at a somewhat lower level and explain some of the configuration parameters. This post is not intended to be a “how does JGroups work” article.

It is important to note that JGroups is used in other areas of a LiveCycle infrastructure:

  • Gemfire (which LiveCycle uses as a caching solution)
  • Content Services
  • 3rd party application servers that host LiveCycle

This post will only touch upon how JGroups is used in LiveCycle Workspace.

LiveCycle Workspace is a Process Management component that provides a web-based user interface that lets users participate in business process activities. When a user is logged in to the Workspace client, that user has to be kept up to date with any activity that involves them, so the use of LiveCycle Data Services is employed as a communication layer between that client and the server. At any time that an event is triggered that would impact the content being displayed to an end user, that information must be broadcast to the data services layer of LiveCycle Workspace, this is where JGroups comes into play.

Getting into more specific detail, JGroups is used to push internal LiveCycle events, such as task creations, task reassignments and task completions out to the Workspace web application (Workspace WAR). These LiveCycle events will be presented to users logged into Workspace as a toast message indicating what has been added, removed or changed for that particular user.

So, how does LiveCycle Workspace use JGroups?

When a LiveCycle event occurs from TaskManager, a component called the RemoveEventDSC contains a JGroups broadcaster that will use multicast to send a message intended for the JGroups listeners in the Workspace web application. Every instance of the Workspace web application will have a listener where it is set up to only consume messages for which it is intended. When a message is consumed by the JGroups listener in the Workspace server component, an update is made to the data services layer, the updates are consumed when that layer is next polled by the Workspace client.


JGroups has a number of configuration parameters that can be changed to accommodate various infrastructure restrictions. All configuration parameters are setup in an XML file which you have to first export using AdminUI, make appropriate changes, re-import and then restart your LiveCycle environment. Here’s where you can get that XML file: Login to AdminUI as an administrative user, click on Services, then click on LiveCycle Workspace ES2 and finally click on Global Administration, the last button on the screen is for exporting the global settings. Click on that button, it will generate an XML file that you can save locally to work on it. Make a backup of the file before making any edits.

In the XML file (AdminGlobalSettings.xml) that you exported, there are 2 items that are relevant to JGroups settings:

<server_remoteevents_JGroupName>

This is the name of the JGroup that is used for broadcast message consumption; the value stored in this setting is auto-generated and unique for each new environment. The only time you would ever change this value is if you copied a LiveCycle database environment to create a new LiveCycle environment.

<server_remoteevents_JChannelConnectionProperties>

Generally the settings found in this element are valid for most networks, however in some cases some of the settings need to be tweaked to accommodate stricter network policies.

Some examples of elements that “could” be changed:

mcast_addr: (Multicast address) – some subnets require a specific IP address range where multicast is permitted; you have to ensure the network IP Address used for multicast is valid for your topology. As an FYI, IPv4 multicast has a range of 224.0.0.0 to 239.255.255.255.

mcast_port: (Multicast port) – as with the IP Addressed used, the port must be available for the subnet where LiveCycle is running. Generally the port number is rarely an issue to affect connectivity; however each network is different, so if communication issues are encountered with an error connecting on the port specified, you should talk to your network administrator to figure out what port to set.

FD: (Failure Detection) – JGroups has built in failure detection; the timeout setting here says it will wait 3 seconds for a response from an “are you alive” message to another JGroup node. If the response is not returned within 3 seconds, a second message is sent, called a “suspect” message (explained next) – You can increase the timeout setting to beyond 3 seconds, but be warned that if failure detection is happening, it means there’s likely something in your network slowing down communication which should be addressed.

VERIFY_SUSPECT: This is a secondary check if the Failure Detection timeout is reached. Only when a FD limit is hit will this second attempt be run to double-check if a member is really not responding. Think of this setting as a means to ensure that a detected failure is really failed by trying again. You can also increase this value, but also be warned that addressing the actual cause of the unresponsive node is more important than increasing a timeout.

There are other settings in the file that should not be altered, if you are curious I suggest visiting jgroups.org for details on the specifics on those additional elements along with any other JGroups specific details you are looking for.

 

——-
Original article at http://blogs.adobe.com/livecycle/2011/03/jgroups-and-livecycle-workspace-explained.html.

LiveCycle ES2 – Using Action Profiles to pre-fill a form for display in Workspace

Seth Reilly

In LiveCycle ES2 Action Profiles streamline the creation and management of pre-fill and custom render services. If you are familiar with this pain point from a previous release you are going to absolutely love the flexibility and power of Action Profiles in ES2.

Let’s pre-fill a form for display in Workspace in less than five minutes…

LiveCycle Version: 9.0

If you get stuck… here is the collateral and completed LCA (.pdf w/ attachments): ES2_Prepopulate

Ingredients:

  • An XML schema (a sample schema is provided in collateral download if you do not have one).

Brewing Instructions:

  1. Launch Adobe LiveCycle Workbench and create a new application.
  2. Expand the application, right click version 1.0 and select New > Form, this will launch the new Form wizard. When promoted for a data model import your schema (The use of a schema is highly recommended, if you do not have a schema you can use a service such as http://www.hitsw.com/xml_utilites/ to create one based on sample XML).
    datamodel
  3. Adobe LiveCycle Designer will launch — Drag a few items from the Data View onto your form. This will automatically bind your form fields to the schema. Save and close the form. If you don’t see any items in the Data View, right click the Data Connection and specify the correct root node in the schema.
    DataBinding
  4. Launch the new process wizard by right clicking your application and selecting New > Process. Choose the following options in the wizard: When a user submits a task in Workspace… & Use an existing Form (select the form you just created)
  5. In the process double click the start point and click on the Manage Action Profiles button.
    ActionProfile
  6. Create a new Action Profile named Prefill.
  7. Make sure your newly created profile is selected and click the Create a Prepare Data Process button, select defaults and click OK. This is going to automatically stub out a new pre-fill process for you. Close the Manage Action Profile dialog and switch back to your process.
    PrefillConfig
  8. Notice that the new Action Profile you just created is now selected for the Workspace Starpoint. Action profiles are tied to a specific form, you can manage them by right clicking the form in the application view or from the startpoint Presentation and Data settings property editor.
  9. Save your main process and open the pre-fill process that was created for you (If you left the defaults intact it should be named [YourFormName]PrepareData).
    PrepareProcess
  10. Examine the stubbed out process — Notice that you already have an xml variable that is backed by the schema that your form is associated with; This is the advantage of using the wizards.
  11. Drag a SetValue operation onto the canvas from the tool bar.
  12. To configure the SetValue, the location should be the node you want to set in your form’s input data (Since you are using a schema you can simply drill down into it and double click it to build the XPath statement).
    x1
  13. For this example let’s set the field’s value to the task creator’s name. Double click the empty [Expression],  drill down into the Task Context and locate the Common Name, double click it and say OK to complete the SetValue operation. x2
  14. Deploy the application by right clicking version 1.0 in the application tree and selecting Deploy.
  15. Test the application: Right click the main process in your application view (or right click in the canvas) and select the Invoke operation. Choose the option to Open the selected start point in a web browser (another nice ES2 shortcut).
    prefilled

Additional Action Profile Tips:

  • For each step in a workflow you may have a different Action Profile e.g. you may want to perform a pre-fill when a process is initiated, but for the second user you may just want to use the default (no-op) profile so that the form is not modified. Action profiles give your this flexibility.
  • An Action Profile set is associated with a particular form. You can re-use the associated pre-fill and render processes but each form will have its own Action Profile definition/set.

Cheers,
_Seth

—-
Original article at http://livecycleapps.wordpress.com/2009/10/21/livecycle-es2-using-action-profiles-to-pre-fill-a-form-for-display-in-workspace/.

Customizing LiveCycle Workspace 9.x using Flash Builder 4.x

- Gilbert Yu
When Customizing the LiveCycle Workspace ES2 User Interface [link] guide was released, it was before Adobe Flash Builder was available for us to do our certification testing. Technically, it is possible to use Flash Builder provided you use the Flex SDK version 3.4.1, ant-contrib.jar file version 1.0b2, and Ant-plug-in as described in the guide. For more information, see the LiveCycle Product blog for steps in the posting Customize LC Workspace ES2 UI using FB4 Premium on 64-bit O/S

In a future release, we plan to complete certification testing and update the guide with updated instructions, but in the meantime, here are some instructions for you to configure your environment to build Workspace customizations using Flash Builder 4. You must complete the last step in the blog when your development environment is a 64-bit operating system.

Happy customizing!

——-
Original article at http://blogs.adobe.com/livecycledocs/2011/02/customizing-livecycle-workspace-9-x-using-flash-builder-4-x.html.

Go to Top