Question

In workflow admin console, testing Forms Web Services URL results in an error.

Workflow Administration Forms

Updated September 11, 2017

asked on January 27, 2015

Clicking Test URL for our Forms server on the DMZ results in the following error popup message in the Workflow Admin Console. No windows event messages are reported in either the forms, workflow server, or local machine running the admin console.

Using SSL on port 443 and it's enabled on the Forms server configuration page, entered into the Web Service URL in admin console and opened in the firewall.

Forms and Workflow are 9.1.1

Thank you for your time!

-Carl

0 0

Answer

SELECTED ANSWER

replied on January 29, 2015 • Show version history

Well, I think it's pretty clear that Forms will use that field to kick off workflows. What isn't clear is Forms also uses that to accept a business process listing request from that same server.

Receiving an invalid SSL handling results in the following error message.

I was receiving the 'doctype error' because Forms was seeing the request come through the Firewall instead of directly from the Workflow server and saying no, your not the workflow server, I'm going to send you a response back you're not expecting. As I was using the full dns name {https://citygov.com/Forms} and thus showing up to the Forms Server as the firewall IP address instead of the Workflow server.

Long story short, all of this can be configured in a few ways depending on what one wants to do with their firewall rules.

We opted to open port 80, both ways, between the internal workflow app server and the Forms server on the DMZ only. This is instead of setting up NAT rules.

Set the Forms WebService in the WF admin console to use:{http://192.168.0.15/Forms} instead of the full DNS name.

Leave the Forms configuration as the specific IP of the internal Workflow server. So it will both expect requests for business process info and direct workflow service tasks to that IP address.

As far as making this more clear, the only change I can think is to either add a second box in Forms config stating: [Allow 'Retrieve Laserfiche Forms Content Activity' to come from the following ip addresses. (Default is same as above)] or to adjust the help file to spell out the behavior of the Forms WebService actually validating the source when receiving a request for business process listing (for the Retrieve Forms Activity).

Another option is to remove the validation all together so anyone with credentials to an account with Process Creator Role in Forms could receive business process listing info. But that's probably a horrible idea for security reasons...

Personally I'd like to see a Forms server be able to send business process info to multiple workflow servers and/or requestors (either spelled out in documention or a seperate config space) because then I could set the same Forms Webservice on Two Different workflow machines and retrieve business process information from the same Forms server while still only having Forms server to attempt to initiate a workflow from one designated Workflow server. (I'm aware the workflow won't run properly if I attempt to retrieve forms content from a Form that won't be sending the workflow request but sometimes when designing it's helpful just to see what's on other servers.)

While this behavior is desirable by me it may create more confusion than it's worth. I'm not sure =p

Maybe another way to add clarity is to have the response behavior for:

When a Workflow server requests business process info from Forms and isn't the expected address spelled out in the Forms config, the response back is understood by workflow as. [This is not the Workflow server address designated in the Forms Configuration page] instead of the general 'doctype' error?

Not sure, but I hope this helps someone out there ;)

2 0

Replies

replied on September 11, 2017 • Show version history

Carl, your notes gave us some good clues about a similar issue we were having. Forms is on Azure and Workflow is on premises.

My contact found (via IIS logs) that the Forms server was seeing the Workflow server's request as coming from the FIOS IP address. He changed the primary Forms URL from lf.ourdomain.com to az-vws-dmzweb1.ourdomain.local, and this worked.

2 0

replied on January 27, 2015

This means the Forms Server is not properly configured for Workflow. Usually, this means that the SSL checkbox for WF on the Forms Config page is checked, but WF is not configured for it. But it could have other causes as well, like not having a Workflow server specified at all on the Forms configuration page, or having the wrong authentication.

1 0

replied on January 28, 2015 • Show version history

Thanks for the quick reply Miruna!

We have the Workflow server specified in the Forms configuration page and have no problem initiating a workflow from Forms with either the SSL box checked or without. The only issue is in the admin console and the retrieve Forms content activity is where we see the error pasted above.

I'm entering https for the url to the Forms webservice but have not specified anywhere else to require Workflow to use SSL.

I've troubleshot some more with the Forms configuration page and found if I specify the workflow server as the Default Gateway of the machine, which is the IP address showing up on the IIS incoming request logs instead of the Workflow server, then we can successfully retrieve business process information in Workflow and use the Retrieve Forms Content activity.

However, by doing this I can no longer initiate workflows from the Forms server.

If I set the IP address to the Workflow server (again in the Forms Configuration Page) then I can initiate workflows but can't use the retrieve forms content activity. I get the error pasted above.

Of course if I put in IP address other than the default gateway or the workflow machine, then both the errors persist where workflows fail to initiate from the Forms service and business process information is unable to be retrieved by Forms activity in Workflow with the identical error message pictured above.

I'll check to see if we can use a firewall rule to allow the workflow IP address to pass to the DMZ Forms Server as itself instead of masked as a request from the default gateway. It appears the Forms Configuration page uses the Workflow Server field for both validating incoming requests for business process information and directing the two outgoing requests. (one to initiate a workflow to the WF Web service and the other to provide business process details from the Forms Web Service).

Thanks again for pointing me in a more specific direction! And please correct any assumptions, I just wanted to add this in as I've learned so much from other people's threads on answers.

Cheers,

Carl

0 0

replied on January 29, 2015

Maybe we should relabel that checkbox in your screenshot to make it clear that it applies to using SSL when Forms connects to the WF server (and that the Workflow Web Service needs to be configured for SSL in that case)? It seems that quite a few people have gotten confused about it and took it to mean that it should be on when Forms has been configured for SSL.