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.
Neotys NeoLoad 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. Neotys provides a downloadable 30-day evaluation copy. Sample project is available (4.8 MB) lc_workspace.zip
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/">
Leave a comment