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

Question

Question

Workflow Web Services call examples

asked on May 8

Does anyone have examples of successful web service calls to a "custom" web service using Workflow?  The Laserfiche documentation doesn't have a whole lot of resources on this.

We are prototyping a workflow web service call to our ERP system, Workday.  We are having trouble with some of the parameters that are required.  We have a test call working in Postman, but workflow doesn't have the same level of configurability.

We are licensed with RIO, self-hosted, perpetual licensing.  We are looking to use OAuth 2.0, make a request for access token, then a second call to execute the actual REST api web service.

 

0 0

Replies

replied on May 8

Hi Charlie,

We highly recommend that you upgrade to Laserfiche Workflow 12 2025H1, which introduces native OAuth 2.0 support for custom web services. That's a long-requested feature we put a bunch of work into specifically so that people didn't have to roll their own OAuth flows. If you have having trouble with the authentication/authorization parts of your web service calls, that will likely solve them for you.

1 0
replied on May 8

Good to hear it is in the latest WF version. I have been using this in the Cloud systems and it is so much cleaner.

1 0
replied on May 8

Absolutely. It's one of the most important features of the 2025H1 release in my opinion.

0 0
replied on May 8

Thanks, that is good to know.  

0 0
replied on May 8

Typically you just need to know the following in order to finish configuring a call to a REST API in the HTTP Activity.

  • URI for the method you want to call
  • Required Headers (which are configured by clicking the gear on the upper right)
  • The Method (POST or GET)
  • The JSON body for POST Method calls

 

I have worked with dozens of different APIs and almost always the documentation is curl commands. So you have to know where to look for what you need.

For example if I see this documentation for the get authorization code method in curl like the following

I know the URI is /auth/oauth/token

No required headers here

The request type is POST

And the body can be copied by copying everything between the single quotes for the --data-raw command

Most often you can also ask AI to convert curl commands to HTTP to get what your looking for as well

0 0
replied on May 8 Show version history

Hi Chad, it was good seeing you at Empower. 

 

I think we're mainly stuck on the proper Host URL, and possibly where we should be including the "body" (client_id, client_secret, etc.).  See below.

 

  1. Host URL - here is Workday's published path, and what is working in Postman where we are executing the Post command.  However, in Workflow, this returns a 400 Bad Request error when setting up the webservice. 
    1. https://wd2-impl-services1.workday.com/ccx/oauth2/[tenant]/token
    2. When we use our application user interface login URL, Test URL authenticates "successfully" returning a 200 level code, but the call to get token isn't successful, returning a "not in the right context" error from our Workday system.
      1. https://impl.workday.com/[tenant]/login.htmld?redirect=n
      2. Returns this in the httpformpost_content:
        1. httpformpost_content

          <?xml version="1.0" encoding="UTF-8"?>
          <wml:Application_Error xmlns:wml="http://www.workday.com/ns/model/1.0" Type="Server Error">
           <wml:Message>No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.</wml:Message>
          ...and 1 more. Double click to see all values.

  2. Authentication
    1. We're using a system account for credentials (not default authentication)
  3. Our URI seem correct based on the Workday documentation
    1. /oauth2/v1/token
  4. Body
    1. Since we are still trying to just obtain an access token, there is no body per se.  
    2. We are currently putting the client_id, client_secret, grant_type, refresh_token in the Form Data section (see attached)
  5. Tool
    1. We started using the HTTP Web Request without success, so we shifted to using the HTTP Form Post.  I wonder if that is also where we are having an issue.  What is the difference?

 

2025-05-08 13_23_41-Workflow Designer.png
0 0
replied on May 8

Oh Charlie! That's right we had a chat at the Starbucks!

I always use the HTTP Web Request as every REST API doc is asking for a JSON body these days. This might be the problem, you might need to switch back to JSON.

I tried looking at the workday.com rest directory, linked below, but I don't see the endpoint your using. Usually it would be under Authorization. Maybe it is hidden from the public?

https://community.workday.com/sites/default/files/file-hosting/restapi/

The URL would be https://wd2-impl-services1.workday.com

The URI is /ccx/oauth2/[tenant]/token

The URI is everything after the domain (.com, .net, etc)

0 0
replied on May 8

I think my original post was the SOAP based URL as that was what Workday Support started us with.  After reviewing the REST API documentation again, I think this is the correct full path:

https://wd2-impl-services1.workday.com/ccx/api/oAuthClient/v1/[tenant]/clientDetails

So hostname is probably https://wd2-impl-services1.workday.com

and URI is /ccx/api/oAuthClient/v1/[tenant]/clientDetails

 

The above is based on a REST call our WD tech got working for us in Postman:  https://wd2-impl-services1.workday.com/ccx/api/timeTracking/v4/[tenant]/timeClockEvents

 

That's good to know anything after the domain is the URI.  That makes it seem impossible/pointless to use the Test URL when setting up the Web Service in the admin console right?

The Workday Rest directory URL is here, but I believe they require you to be a customer or partner with an account to view it.

https://community.workday.com/sites/default/files/file-hosting/restapi/index.html#customObjectDataSingleinstance/v2/Custom-Objects

 

0 0
replied on May 9

This link takes me to custom objects. I was looking for the method you use to get your Authorization Bearer token. The way these OAuth2.0 APIs work is you first need to make a call to a token method with your client id and secret, then it returns a token. Now you can use this token in your header to access all other methods for a limited amount of time instead of passing your password on each method call.

So you must first call a method like /token at the start of your workflow and it returns a token as a long string of characters. Then as you call methods to actually send and receive data for the rest of the workflow you just add the header "Authorization" with value "Bearer yourtokenstring"

This whole thing is automated for you in Version 12.

Testing the URL should still work, usually the URL will still respond with a 200 as your not asking it to run a method with a URI. It is just the home base website.

I created a workday integration once in 2017, but it was so long ago I can not remember any of the details. Most all these API's work the same now from my experience (except the ones that require a code in addition to a secret)

Your just looking for the documentation for the Authentication method.

Run far away from anything labeled SOAP. In my experience this just means they wrapped their SDK with an interface. You basically have to know their SDK which means you need to be a developer. I never see this term used anymore. Everyone is using REST now because it's simple, secure, and you don't have to be a developer to understand it. Other than the confusing authentication requirements, the methods themself are all listed with a URI and you use JSON to organize your information which is much easier to read than XML.

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

Sign in to reply to this post.