Load-Testing LiveCycle Workspace Applications

Since LiveCycle Workspace ES is an application built with Flex, load-testing business processes (long-lived orchestrations) built with it can be a challenge if you are using versions of LoadRunner, SilkPerformer etc that do not support the AMF3 protocol.

If you are using HP LoadRunner or IBM Rational PerformanceTester, adding the flex-messsaging-*.jar files to your project’s CLASSPATH will help in deserializing Flex AMF3 messages while you are recording the test case. You can get all of them except the one for data management from Adobe’s open-source BlazeDS project.

The following JAR is part of LiveCycle Data Services (LCDS). If you have licensed LiveCycle ES2 or ADEP Document Services, you can get it from %LC_INSTALL_ROOT%\LiveCycle_ES_SDK\misc\DataServices\Server-Libraries\
6) flex-messaging-data.jar

NeotysNeoLoad supports AMF3 natively. If you have prior experience with load testing tools, you can get a load-test scenario for Workspace developed and running in about 4-6 hours using NeoLoad. See demo here. Neotys provides a downloadable 30-day evaluation copy. Sample project is available (4.8 MB) lc_workspace.zip. I’ve had one person report that the project does not parameterize oid properly. If you hit problems, please make sure you fix that.

Immediately after recording a scenario, it will ask you for the flex-messaging-data.jar file. You can obtain it from %LC_INSTALL_ROOT%\LiveCycle_ES_SDK\misc\DataServices\Server-Libraries\

Please note that the forms used in the process should be XDP, not PDF. Also, ensure that Process Management ES works in your environment. Instructions are available here.

As most experienced load-testers know, the trick to developing solid load-test scripts is knowing which parameters are dynamic and therefore have to be parsed out of server responses and re-used in subsequent requests to the server. For Workspace ES in 8.2.1 (Update1), these parameters are as follows:

JSESSIONID

The JSESSIONID (B93D4FA6F9FDA1911CD701FB5C310887) is returned by the server when you load the login page (/workspace-server/determine-locale) as this, for example:Set-Cookie: JSESSIONID=B93D4FA6F9FDA1911CD701FB5C310887; Path=/

authData

authData (c3RAQENDIyNhdUBAMA==) is also returned by the server when you load the login page (/um/login) as this, for example:Set-Cookie: authData=c3RAQENDIyNhdUBAMA==; Path=/

lcAuthToken

lcAuthToken (272ED3A8-D412-8068-E1F3-610FF7CFE531) is returned by the server when you login with a userID and password (/um/login) as this, for example:Set-Cookie: lcAuthToken=272ED3A8-D412-8068-E1F3-610FF7CFE531; Path=/

oid

oid (9EF6E50E-FAE4-93A0-A70C-580518BC4AD9) is also returned by the server when you login (/workspace-server/authenticate) as this, for example:valid=true&oid=9EF6E50E-FAE4-93A0-A70C-580518BC4AD9&userid=rwoodard&displayName=Rye+Woodard

When you submit the form, the value for AWS_ASSIGNED_ID has to be parameterized with the value of oid as follows:<AWS_ASSIGNED_ID>${oid}</AWS_ASSIGNED_ID>

taskId

The taskId (111) is returned to you in an AMF message when you start a process by loading its init form. You cannot parse this unless your load-test tool understands AMF3. It looks like this:<taskId tagClass=”double”>111.0</taskId>

When you submit the form, the value for AWS_TASKID has to be parameterized as follows:<AWS_TASKID>${Task_ID}</AWS_TASKID>

formName

The URL for the form is also returned to you in an AMF message when you start a process by loading its init form, for example like this.<url tagClass=”String”>http://localhost:8080/workspace-server/documents/3727297134487800504-9.pdf</url>

The form name (3727297134487800504-9) will change from invocation to invocation and has to be parameterized for your load-test script to work.

When you submit the form, the value for pdf href has to be parameterized as follows:<pdf href=”http://localhost:8080/workspace-server/documents/${Rendered_Form_Name}.pdf” xmlns=”http://ns.adobe.com/xdp/pdf/”>