Posts tagged "template_url"

LiveCycle ES: old XDP templates with invalid WSDL URLs used for running processes

Issue

 If you have migrated from LC7 to LC ES and you were using webservices in your XDP templates in LC7, you may have modified these templates after the mgiration to LC ES to use updated WSDL URLs.  You may notice however that even for process instances started in LC ES the old template version is still being used, and so the invalid WSDL URL which means the tasks will no longer work as expected.

Reason

In LC7 we set both the template_url and hardened_template_url fields in the tb_form_data table to reference the forms used in LC7.  In LC ES we no longer use the hardened_template_url field for new LC ES processes.  However for processes migrated from LC7, we still use this field to reference the exact version of the form that was used to start the process.

The template_url field in tb_form_data contains only the URL to the form in the repository (/Forms/form1.xdp).  The hardened_template_url contains a timestamp with the URL to reference a particular version of the form in the repository, and can therefore referenence different versions of the form (@1271757648748/Forms/from1.xdp).

Solution

If you set the contents of hardened_template_url to empty in tb_form_data, then LC ES will use the template_url by default, which does not have a timestamp, and therefore will always refer to the latest version of the XDP form in the repository.  This will ensure that your updated XDP template with updated WSDL URL will be used for each process.

You can run the following SQL statements first to see how many rows are going to be changed:

Statement1:

This is used to check which forms are being used for active tasks which have a hardened URL set.  These are the forms that are going to be modified by the SQL query, so they should relate to the forms you have modified for the WSDL changes.

SELECT DISTINCT f.template_url, f.hardened_template_url
FROM tb_form_data f
WHERE f.task_id IN (SELECT t.id
 FROM tb_task t
 WHERE t.status < 100)

Statement2:

This is used to ensure that there are no NULL entries in the template_url field.  The template_url field is the field we are going to use to refer to the modified form. Therefore, this statement should not return any rows.  You should probably run this statement again checking for “ “ instead of NULL values just to be sure there are no empty strings in template_url.

SELECT t.form_data_id, f.id, f.template_url, f.hardened_template_url
FROM tb_task t, tb_form_data f
WHERE (f.template_url IS NULL) AND
 (f.hardened_template_url IS NOT NULL) AND
 f.task_id IN (SELECT t.id
 FROM tb_task t
 WHERE t.status < 100)

Statement 3:

If statement2 does not return any rows, then you can run this SQL to actually make the required changes in hardened_template_url.

UPDATE tb_form_data
SET hardened_template_url = NULL
WHERE (template_url IS NOT NULL) AND
 (hardened_template_url IS NOT NULL) AND
 task_id IN (SELECT t.id
 FROM tb_task t
 WHERE t.status < 100)

Notes

If you are unsure about applying these SQL queries to the Database, or if this occuring in a production environment, then contact your support representative to discuss the workaround and to verfiy the results of the first two SQL statements.

reference: (181544186)

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