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

Question

Question

Laserfiche Workflow API Response

asked on April 27, 2020 Show version history

Hey everyone

 

Quick question. We currently use Laserfiche for all of our internal forms and business processes and are currently in the process(In the next year or two), switching them on for our external processes as well. 

Because of this, I've started deep diving more into the Laserfiche Workflow API, with the hopes of building more custom applications around Laserfiche and Workflow when needed. I've dived into the API before but only on smaller scale projects and mainly as a means to an end.

 

So here is my situation. In test, I have setup a small webhook in Python that can hit the Workflow API and pass parameters.

 

import time
import requests
from requests_ntlm import HttpNtlmAuth
import webhook_listener



def process_post_request(request, *args, **kwargs):

    workflow_url = "https://xxx-workflow-url-here"


    r = requests.post(workflow_url, json={"ParameterCollection":[{"Name":"testParameter", "Value":"HELLO WORLD"}]}, auth=HttpNtlmAuth('domain\\xxxxxx','xxxxxx'))

    print(r.content)

    return


webhooks = webhook_listener.Listener(handlers={"GET": process_post_request})
webhooks.start()

while True:
    print("Still alive...")
    time.sleep(300)

Again, this is just test server to test server, all internal. Here is where the problem comes into play.

 

As soon as the workflow INITIATES, it returns a response like this.

 

b'<InstanceCreationResultData xmlns="http://schemas.datacontract.org/2004/07/Laserfiche.Workflow.ComponentModel.DataContracts.Creation" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><fault><Status xmlns="">0</Status><Detail i:nil="true" xmlns=""/><DetailCode xmlns="">0</DetailCode></fault><instanceId>UUID-HERE-FOR-EXAMPLE</instanceId></InstanceCreationResultData>'

This is all fine and good, and it's great to know that the Workflow Initiated, but I don't want the response to be returned UNTIL AFTER the workflow has finished, not when it initiates. 

 

 

I would want the response to come back AFTER the End Workflow step is complete, that way I could also have more flexibility if I wanted to put features like Try/Catch...I could relay to the end user the status of the workflow.

Does anybody have a solution for this or encountered this before, am I doing something wrong? Is there an option I can pick to relay the workflow status back up instead of "Yeah your workflow started."?

1 0

Answer

SELECTED ANSWER
replied on April 27, 2020

That's expected behavior.  The only way you're going to be able to communicate back is from inside the workflow where you can POST back to some URL, talk to a named pipe, send a queue message, write a text document, make a database insert ... something like that ... and then monitor those outputs :(

 

You want direct communication and real-time UI updates, the SDK is a better route.

3 0

Replies

replied on April 27, 2020

Hey Rich

Thanks for the response back.

To me that seems like a huge integration let down on Laserfiche's part. The SDK is good but the only time I honestly use it is within Workflow itself and sparingly(trying to accomplish things that are not within the Workflow Task/Toolbox realm).  Most of my applications(Web and otherwise) are written in languages like Javascript, PHP and Python, so to be able to CONTROL the pipeline back up to the request and render information about the Workflow completion status out of the box would be amazing instead of having to have a clunky solution like POSTing back to ANOTHER web hook or monitoring a database.

 

Thanks again for the response back!

1 0
replied on April 27, 2020

I used to feel the same way, believe me!  I used to put in all kind of writes to a message queue within the workflow, and monitor the queue to do UI updates.  It was exhausting, and difficult to maintain.  But if you look at the context of LF Workflow - being built using the Windows Workflow Foundation (WF) - workflow is, by nature, not in the UI context.  I've totally flipped my approach on alot of things, as far as workflow goes - especially as it relates to Import Agent and Quick Fields Agent.  I mostly use workflow to send a message somewhere to do all the heavy lifting - probably a Windows Service, so I can debug code easier.  For true UI interaction, I save alot of time just writing what the workflow is supposed to do in the SDK, deliver UI updates, and have more control over over debugging.  But then, I'm a .Net guy and everything integrates seamlessly.  For JS, PHP, and Python - you're always going to have to jump through hoops when it comes to integration, but I feel your pain.

1 0
replied on April 27, 2020 Show version history

All that makes sense and thanks for your help!

I think it would be great if Laserfiche had a better HTTP Rest API. Like, login with an auth token, and then use HTTP to do certain actions against the repository and other components, like retrieve documents, store documents, Get/Start a workflow and get it's status, etc.

I know all these options are available with certain aspects of the Software, like you said, IMPORT AGENT(For storing documents), Web Access(For retrieving documents), etc, but it would be cool to have them all under one HTTP REST API.

Thanks again for your help Rich, you've been extremely helpful and it's good to know I'm not the only one facing some of these frustrations at some point :-).

1 0
replied on April 30, 2020

Also just wanted to update....after I wrote the above response about HTTP REST API I found this Laserfiche Answers post as well while doing a little more digging. Spot on!

 

https://answers.laserfiche.com/questions/168986/Discussion-Will-Laserfiche-ever-get-a-unified-RESTful-HTTP-API

 

Everything the poster is saying in that article would definitely help developers like me(Javascript, Python, PHP, etc) integrate Laserfiche seamlessly across multiple languages and platforms without having to jump through a lot of hoops.

1 0
replied on April 28, 2020

Hello,
You will find attached a sample workflow call using the workflow SDK and an example to monitor the workflow process.

below are the references to include
using ...
using Laserfiche.Workflow;
using Laserfiche.Workflow.Objects;
using Laserfiche.Workflow.Objects.Instances;

invoke_wf.txt (2.37 KB)
1 0
replied on April 30, 2020

This is another probing mechanism, btw

1 0
replied on October 20, 2020

Found this thread   https://answers.laserfiche.com/questions/70701/REST-API--Workflow-Web-Service

 

Anyone did follow and program a callback URL?

0 0
replied on October 20, 2020 Show version history

Hey Luke

 

Just FYI I believe the person that wrote that post(Rich), also responded to this post and had the top answer.

 

I believe his post scenario was initially similar to mine. He, like our organization, stumbled upon the Workflow Web Services and was trying to figure out how to do certain things with it, I.E., mainly poll for a response back.

 

It's been a few Months since I wrote this post and we have explored the Workflow Web Services way more in depth. Here are a few takeaways that we realized after writing this post.

 

#1. The workflow web services are good for what they are. They give you the ability to start workflows from any custom made application. You really can't do much AFTER you start the workflow without either using .NET OR writing some custom polling mechanism(as Rich pointed out).

#2. It actually makes sense for the Workflow to give a message upon execution instead of the end, because Workflow run/execution time can take AWHILE, there is no set limit, you wouldn't want to tie up a web service on a long running workflow, waiting for a response back.

 

#3. The SDK is BETTER for situations where you want to integrate and get immediate responses back. The unfortunate part about this, for our organization, is none of us are .NET developers. Everyone on our organization's development team comes from Linux backgrounds(Slackware here, for YEARS), so we aren't exactly quick to embrace .NET either. 

 

We've changed our approach to Laserfiche integration in terms of custom applications. We pretty much incorporate Laserfiche into our development stack to handle things that we might want to keep low code. Laserfiche workflow is still great for doing things you would have to code out, and the user doesn't need an immediate response BACK.

I think the bigger issue lies in the fact that Laserfiche lacks a Universal REST API for handling tasks, as noted in this post.

https://answers.laserfiche.com/questions/168986/Discussion-Will-Laserfiche-ever-get-a-unified-RESTful-HTTP-API

 

Sure, Laserfiche gives us all these cool tools for accomplishing integration tasks(Import Agent, Workflow, Workflow Web Services, Forms, etc.), but ultimately a unified REST API would be great and solve a lot of problems we face when using other programming languages outside the .NET realm.

 

On a side note. One programming language we have recently started using where I work, is a programming language called Go(Golang). We DID release a Workflow Web Services API client in Go. This client has proved to be successful for us because we can integrate it into custom web applications we build in Go.

https://github.com/CabarrusCo/lfwfapi

1 0
replied on October 20, 2020

hi Mark, thanks for the long detail explanation of your work and thoughts. I fully understand the Laserfiche Workflow (system) are working on their own pace/logic so any submitted requests may take long to finish or for some reason stay suspended/end with exception etc.  What I am really interested in about the hidden parameters that set up a callback URL which allow workflow system reporting back to that URL of something happens to the workflow (complete? terminated? etc.)  in that post.  I believe It's the way that Laserfiche Form's process calling a workflow which allow "waiting for workflow to complete" then go to next step happen.

Anyway, very nice to see people share their work/experience which greatly short our research/discovery time.

 

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

Sign in to reply to this post.