Is there any particular ports that has to be open or any specific configurations in order for the Forms server and Workflow server to communicate properly? The Forms and Workflow is installed on two separate servers, but when I use a Workflow Service Task in the process to start a workflow, and select 'Yes' to 'wait for the workflow to finish before proceeding?', the workflow triggers and runs successfully, however on the forms server side the process is still stuck on 'In progress' for the workflow service task. It seems to me that the workflow server is not communicating back to the forms server properly to notify that it has finish running the workflow. Does anyone have any idea? Thanks.
Question
Question
Replies
Workflow will need TCP 80 & 443 (HTTP & HTTPS) in order to exercise the Forms API.
The remainder of this explanation is by deduction, but based on my observations and experience with implementing the same functionality. Presumably the starting of the workflow, and the notification of workflow termination occur asynchronously. I.e., The call from Forms to the Workflow API doesn't sit and wait for the Workflow to complete; it just kicks off the workflow and then closes that communication session, noting in its own database that the Workflow was started. Separately, once Workflow has completed that instance, Workflow then posts that back to the Forms API, which updates it's record of that instance being completed.
Because they aren't part of the original TCP session, and are initiated in opposite directions, you need the FW communications to allow that communication to be initiated from either side:
Forms == TCP 80/443 ===> Workflow
Forms <== TCP 80/443 === Workflow
Hi All,
We are also seeing the same behavior. We are currently using Forms 10.2.1.205 and Workflow 10.2.0 and it seems that every forms instance that uses a Workflow Service Task gets stuck on "In Progress" if the Wait for workflow to complete before proceeding option is checked in Forms - even though the workflows are completing successfully. There are no errors being displayed in the event viewer.
Thanks, Dan
Hi Dan, a few things to check.
In Forms Configuration, change the Primary Server and Notification Server lo localhost (if all modules are on same server) or the actual server name (Do not use the FQDN). Restart the Forms Routing, Workflow, and Notification services.
Open Workflow Administation Console and configure the External Objects, WebServices to match the Forms Primary Server Name. You'll need to open the workflow and update the Retrieve Business Process Variables Forms Server connection and republish the workflow.
Suggest you make up a simple process to test as opposed to changing in production workflows until you get it straightened out.
Not sure if this will work for anyone else, but after a while trying different things turning on "Windows Authentication" in IIS did the trick for me - it seems the account Workflows was using was getting an "Unauthorized" error from Forms (even though there were no errors displayed in the Event Logs). I did the following:
- Open Internet Information Services > Sites > Default Website > Forms
- In "Authentication" enable "Windows Authentication"
- In "Application Pools" recycle the Forms App Pool
- Restart the Workflow and Forms Routing Services
I had the same issue raised today and the resolution was to use a FQDN as the primary Forms server URL. Forms and Workflow were on different servers and I guess workflow was previously trying to notify a localhost Forms URL (and the Workflow server did also have an unused instance of Forms installed).
After the change was applied all the forms processes would then appear as "Completed" rather than "In Progress".
Is there any error in the event log on the Forms server when the workflow service task get suspended?
There are no errors in the event log, since the workflow service task stays 'In progress' indefinitely rather than suspending itself.
Check in the WF Admin Console under Advanced Diagnostics\Failed Instance Completions. Is there anything listed there?
The error I'm getting is Unable to connect to the remote server.
The Instance in forms Service task shows "in progress" although the Workflow has completed, and as I had set "wait for workflow to complete" the process is basically hung. more details on how to correct this please. FYI, my WebService configuration works fine to retrieve the Form BP Variables, and all modules are on the same server. Details on how to fix this please.
Hi @████████
I have similar case where the WF used to save data into DB, I checked Failed Instance Completions list in WF Admin Console under Advanced Diagnostics and I found that the WF instance generated the following error "Specified value has invalid CRLF characters.Parameter name: value".
Any idea what this error means also is there away to complete the instance without terminate it and resubmit new instance.
Regards,
Nadeem
What version of Workflow are you using? This has been fixed in Workflow 10.2.1 and higher.
Workflow version is 10.2.0
Can we execute the workflow service task again and complete the current instance?
This error occurs when your workflow instance terminates and the reason for its termination contains a newline character. You can execute the workflow task again if you know it will complete rather than terminate.
The workflow used to save data into database and we can remove any newline characters but how we can execute the workflow again?
The Forms task would be suspended if it is waiting on Workflow to finish. So you can retry it.
Would you mind reviewing my scenario that is similar?
Good day,
We were having the same symptoms being presented above with no errors being reported in any of the logs or event logs on either of the 2 servers. Our Forms Server (A) is on a separate Server from Workflow (B).
Our problem:
The issue started after we moved from LF Forms 10.2.1 to LF Forms 10.3.1. We had uninstalled 10.2.1 and did a fresh install of 10.3.1 and pointed it to the DB that held all the forms Data. The DB was then upgraded through the normal install process and once we started testing, we found that all the processes that involved invoking a Laserfiche Workflow, did not go past that step. The Workflow would complete successfully, no errors or warnings being presented.
We even created a new test Process to make sure it was not something that went wrong with the migration / update of the data on the DB side. Trying different options, we eventually narrowed the problem to the Forms server (A) as we could successfully run the same process form a different Forms Server (C) to Workflow Server (B). But when trying to run the process from Forms Server (A) to another Workflow Server (D) it behaved the same.
We then tried Un-installing the LF software on Forms Server (A) and ensure now temp files were remaining on the server before doing a fresh install again. Yet after the install it still did not work. A request was logged via our VAR to LF support that initially said that the problem had to be with the Workflow Server. This did not make sense seeing as we could successfully complete processes from a different Forms Server (C) to the same Workflow server.
Another suggestion that came was to do a Complete format and reload of the server and doing a fresh install of the software again. We decided to dig a little bit more and happy to say that we got to the bottom of the issue.
The Fix:
We decided to check the network traffic that was been sent between the Forms Server and the Workflow Server in each case A to B and C to D. We noticed that between A to B, the comms started of on Port 80 and then switched to port 443, which then did a reset and seemingly went into a loop trying to get the comms through.
Between C and D, this was not the case and everything stayed on Port 80. We then went through a process to compare each setting between server A and C and visually everything seems exactly the same. All url’s were configured with http and not https and we had no block ticked to use ssl.
Eventually when checking the DB tabled for forms, we came across an entry (FormsHost) in the cf_options table were the URL reference was set to “https//:…” and not “http//:…” . The strange thing was that on FormsConfig, the host was showing http: so not sure how this was changed to https:. Changing this entry, restarting the FromsRouting service, resolved our issue and now the process work like they did before.