You are viewing limited content. For full access, please sign in.

Question

Question

Workflow - Web Service Reference in Workflow Script?

asked on June 13, 2014

I am looking for a way to add a web service reference xml file to a workflow script object.

 

This is for a salesforce integration. I would prefer to use the http object but they don't provide any URIs that include authentication in their REST API.

 

The only solution I can find is a programmatic authentication using their web reference.

1 0

Replies

replied on June 13, 2014

Rather than try to deal with this inside the Script activity itself, I've been creating a separate Visual Studio project and building an assembly that wraps all of the functionality and services that I need and exposes a simple API. Then I reference that assembly in the Script activity and consume the API.

 

It allows me to avoid any limitations of the scripting environment but still allow Workflow to communicate with outside systems.

1 0
replied on June 13, 2014

Good to know, I am not familiar with building APIs but if it is not too complex it might be a route. I am trying to keep the integration from bloating too much, which is why the HTTP integration are so valuable for the vendors that offer it.

1 0
replied on June 13, 2014 Show version history

What I mean by an API can be as simple as creating a DLL with a single class and some public methods:

 

 

Then in the Script activity:

 

Add a reference:

 

Import any namespaces:

 

 

Call it like any other object:

 

From there on, it's just a matter of normal Laserfiche scripting. It's pretty straightforward.

 

You can abstract as much or as little as you want. In my case, I went that direction because the capabilities of the scripting environment provided by Workflow weren't adequate. Also, the integration required a lot of data manipulation before I could send the information to the service. So there's over a thousand lines of code and a couple of dozen classes. Your assembly might only your service reference and a single class and one or two public methods.

 

1 0
replied on June 18, 2014

This appears to work great, I can see all my functions and even the Web Reference methods after adding my DLL file. However the workflow service can't see the file when it goes to run, it errors out saying that it can't find the file. I have tried running the service as local host and my domain account, also tried moving the dll file to the workflow program files folder and referencing it from there.

 

1 0
replied on June 18, 2014

So, that's a goofy caveat to how references in Workflow work. Try copying your DLL file, and it's accompanying .config file, to the root of the workflow directory. (C:\Program Files\Laserfiche\Laserfiche Workflow 9)

 

I've also noted other path related weirdness, so when I add the reference, I created an identical path on my workstation and I copy my files into that directory, then I add the reference from there. I'm sure that there's a better way, but I spent a lot of time on it before I hit on something that worked.

 

Once you add the reference and get the workflow published, you can update the DLL in place directly on the Workflow server. You might need to restart the Workflow service to release any file locks. 

1 0
replied on July 18, 2018

So I followed what was described here in this post.  I did copy over the DLL and DLL.config files to the  (C:\Program Files\Laserfiche\Laserfiche Workflow 10.2) directory.  However, I got this error:

 

It seems as though the DLL is not able to find the config file even though it is in the same directory.  How would I proceed in this case?

replied on August 22, 2018

Hello,

We have a client that followed this post and created a DLL they could add to the Script Activity in Laserfiche Workflow. They copied the DLL and the .config file into the folder mentioned at the bottom of the post. Then they were able to add a Reference to the DLL in the Script Activity but when they ran the workflow they received an error that it "Could not find endpoint with name 'AuthorizeSoap12' ...' " which is one of the endpoints listed in the .config file. They were wondering what could be causing the DLL to be unable to see the .config file even though they are in the same folder as described in the forum post.

We realize that at the time of this answers post, it probably is relating to Laserfiche 9, as they currently are on version 10, not sure if this changes anything. 

0 0
replied on August 22, 2018

They copied the assembly and config file to the Workflow direction on the Workflow server? Are there any other aspects of the assembly that reference the config file and are working?

0 0
replied on August 22, 2018

Woo woo woo.  How is it I posted this same question here over a month ago and never got a response.  Then created this post https://answers.laserfiche.com/questions/145003/Using-a-Web-Service-Reference-in-Workflow-Script thinking maybe this was an old post so no one looks at it and I've never gotten a response.  But now a VAR posts a questions and get a response almost immediately?

0 0
replied on August 22, 2018

To answer your question, no the config file is strictly for the DLL and is not being used for anything else.

0 0
replied on August 22, 2018

FYI, I'm just a user. I don't discriminate between anybody who needs help. I apologize that I missed your other post, otherwise I might have been able to help. The only reason I saw this one is because I got a notification.

0 0
replied on August 22, 2018

Devin, I was going to message you privately but there doesn't seem to be a way to do that.  I do apologize for blurting out.  It wasn't necessarily directed at you.  It was more frustration that I posted a reply to this post early July and then created my own post in mid-July but never got any responses.  Then I turned to our VAR, who then posted a reply here :(.  I was like .. ummm.. I already tried that.  Then I saw your response like immediately, I was like .. wait what? So, yes, my apologies.  It was uncalled for.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.