Invoke Workflow on Alternative Workflow Server

asked on May 17, 2019 • Show version history

I followed the instructions to invoke a workflow on an alternative workflow server but the workflow never starts.

The instructions are pretty basic, no special security configurations or anything is mentioned.

To configure Workflow Server

Add the Invoke Workflow activity to your workflow definition by dragging it from the Toolbox Pane and dropping it in the Designer Pane.
Select the activity in the Designer Pane.
Click the Advanced button at the top of the Properties Pane.
Under Workflow Server in the Properties Pane, select to use the current Workflow Server or type the name of the server you want to run the invoked workflow.

When testing, the workflow wraps the activity in the color green, which (kind of) means successful.

But on the remote server, the workflow never started.

0 0

replied on May 20, 2019

Just by watching the workflow activity on the alternative work server. My "Invoke Me" workflow which it said it successfully started has no instances.

The reason I am using this is so that I can start workflows on a 32-bit workflow server in order to communicate with a 32-bit ODBC driver. Is there a problem with the bit-differences in the request?

From the primary workflow server, using the Invoke Activity, I can see all workflows, and even open the workflows from the alternative server. It just will not invoke and doesn't throw any errors.

0 0

View 6 previous replies

replied on May 20, 2019

Check the message queues on the destination Workflow Server (Computer Management\Services and applications\Message Queueing). See if you have any messages waiting in the lfwf_creation queue or in the transactional dead-letter messages. You may have to turn on journaling for the lfwf_creation queue and reproduce the issue first.

0 0

replied on May 20, 2019

Ok, I should be able to check this tomorrow

0 0

replied on May 21, 2019

No luck finding anything on the destination server, even after enabling journaling. The description of journaling though is that it is only to track sent messages and the destination server is on the receiving end so I wouldn't expect to find anything sent from there.

So I instead tried enabling journaling on the initiating server but no luck there either. However I do see something on the initiating server under outgoing messages, here is a screenshot.

"batman" is the destination server

0 0

replied on May 28, 2019

Can you check the Transactional Deadletter queue under System Queues? Is the Workflow Server service on the source machine running as a domain user?

0 0

replied on May 28, 2019

I think I found it in the Transnational Dead Letter queue today, from some of Friday's tests.

It says Access is denied for queue DIRECT=OS:batman\private$\lfwf_creation

Workflow services are all running as Local System

0 0

replied on May 28, 2019

Ok, that's what I was expecting. If you change the WFServer on the source machine to run as a domain user with rights to write to the queue on the destination machine, this should clear up.

Don't forget to turn off journaling when you've made it all work.

0 0

replied on May 29, 2019

I am not sure how to grant a user access to the queue? Is being a local administrator not enough?

Here is what I tried, since I do not have rights to create domain users.

I created a local admin on both servers and added them to the logon as a service security policy. Both accounts use the same username and password so that they will have mutual access to both operating systems. Then I switched the workflow services to run as these accounts and verified there was no errors in the workflow logs.

It did not resolve the Invoke issue though. I am wondering how it is that I can see and select the workflows from the Invoke activity if they do not have rights to talk to each other.

0 0

replied on May 29, 2019

You can right-click on the queue and open its properties. Then there's a Security tab. However, local users won't help since they can't get out of the machine. You need to add rights for WFServer A's service user to the queue on WFServer B. As far as B is concerned, any local users on A don't exist.

0 0

replied on June 11, 2019

Something is not pickup up with the security. By default the Everyone account is already selected with the ability to Send Messages, I tried promoting it to Full Control and I still get Access Denied.

Finally came up with a workaround since both servers can see the same repository, created a template with key value paired multi-value fields to work as a dictionary for passing parameters.

0 0

Question

Question

Invoke Workflow on Alternative Workflow Server

Replies

Sign in to reply to this post.