xmlwfic stuck in workflow

[madhuusa]

Team, AppNair,
We have a weird situation. We have couple of workflows with xmlwfic step. This step basically calls a servlet which then comes back and fills in form data after which the workflow continues.

In one specific workflow, we are seeing that the workflow step is stuck for xmlwfic and the servlet is called correctly and the form data is filled but workflow kind of does not proceed.

We have other workflow's in which xmlwfic which does similar thing works correctly and workflow progresses.

The form is not required (in xmlwfic 3.0.0 I think a patch was issued for this specific issue) and we even applied the patch.

Have any of you faced this issue recently with xmlwfic. This is for LL 9.7.1 and from the logs we are not able to track anything in terms of error and the workflow is also stuck.

 

[madhuusa]

My apologies. The above was without any details. We managed to dig more and this is the following.

XML returned back to Livelink xmlwfic:
<?xml version="1.0" encoding="UTF-8"?>
<!-- Result of REG AFS Update Operation -->
<exec xmlns="

http://www.opentext.com/llx/"><edittask

xmlns="

http://www.opentext.com/llx/workflow/"

status="done"><userdata><forms><form name="KSS Disb Form Data"
inherit="1"><attribute name="KSS_UPDATE_ERROR_CODE">
<value>3</value></attribute>
<attribute name="KSS_UPDATE_ERROR_DESC"><value>Wire Status - INVALID FIELDS [ Obli == 89283, Obligation == 26, KIP AccountNumber ==
67876, Wire Amount == 12.25 ]</value>
</attribute></form></forms></userdata></edittask></exec>

Instead of inserting error code 3 (kss_update_error_code), livelink inserts a value called L1 (below) in the insert statement and naturally the oracle database throws the error saying invalid value ora 984 error. below is the insert in oracle.

REQUIRED. [ Obli == 89283, Obligation == 26, KIP AccountNumber ==
67876, Wire Amount == 12.25 ]', L1, 'ka-ent\jnoah',
'uwiduskduZaz6Yvt=', 'K', NULL, NULL, NULL,

Have you guys faced any thing like this in workflow/xmlwfic? Note that we are not inserting this record manually by any sql or trigger. Since the form is associated with the workflow and xml data is being passed back to the form and the action is update on the xmlwfic the form data is being inserted by Livelink.

there was a patch at

https://knowledge.opentext.com/know...c.Fetch&nodeid=14688968&docTitle=pat09189.txt

for a similar kind of issue.

# If a form is attached to Workflow and it is required, and if that form is made # available in any XML Workflow Interchange (XMLWFIC) step, the step will not complete because no user clicked the Apply button on the form to indicate the form was viewed and or updated by the user.

but in our case the form is not mandatory/required and also many xmlwfic steps work even with form (not mandatory/required) attached and we applied the patch still with no use.

 

[madhuusa]

Just another quick info. We upgraded our QA system from 9.5.1 to 9.7.1 and this WF issue is there.

Looks like couple of issues people are complaining when upgrading on WF. Another issue is here at

https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=15676291&objAction=view

 

[madhuusa]

I think the issue is kind of resolved. We are validating more to make sure it works.

The issue is the Number(10) in form template and the Number(22) in the table for that particular column. We have other columns also of differing sizes but those columns have NULL values during insert and so did not come in the radar. Once we bought table to Number(10), the 'L' appending does not happen

This is a table of huge columns and hence we were getting dragged in several directions chasing various constraints/columns/validation/etc - not sure when OT will make LL Forms much more smarter so that you can relational kind of form/table structure in a nice way thereby eliminating huge tables and hence issues that come along with it. Probably not, as they have EForms to sell I guess

It is weird though. I guess you can have different size in table vs template as long as the table column size is bigger (so as to avoid data loss) and not sure why Livelink puts 'L' when it is the case.