Hoppa till huvudinnehållet

Running Server Side Workflow via REST Endpoint

Andrew Kesterton

Hi,

 

We have a Workflow 5 Server Side Workflow that is working great, but we would now like to automate (via a webhook from another process). I've looked at how the server side workflows are called, but can't find any documentation describing this. Is it supported to call server side workflows via the workflows REST endpoint, and is there some documentation for the process?

 

From what I can see you first call 'Geocortex/Workflow/service/auth/token/run' with an ArcGIS Portal token to obtain a 'GeoCortex' token, and then submit a job with the token to Geocortex/Workflow/service/job/run that runs the workflow.

 

This works and I have been able to test from our external service, but I'd like to know if I have followed the steps correctly and this is a supported use for GeoCortex Workflow 5?

 

Thanks and have a good weekend all,

 

Andrew

1

Kommentarer

11 kommentarer

Datum Röster
  • Ryan Cooney

    Hi Andrew,

     

    Yes, your approach sounds correct.

     

    Also, we will be providing documentation of the Workflow Server REST API in an upcoming version (similar to what we do for Printing and Reporting). In the mean time you can load the attached swagger.json file into any Swagger editor (like https://editor.swagger.io/) to see a preliminary version of the documentation.

     

    --Ryan

    0
  • Andrew Kesterton

    Great thanks Ryan for your reply.

     

    Good to see in Swagger that the API that it will accept webhooks directly from Survey123 (this is what we are doing at the moment but via Integromat). That will really help us being able to link the two together 😀

    0
  • Ken Lyon

    @Andrew Kesterton? You can run a server workflow from a survey123 webhook now, although I think we've not yet documented it. It was added in v5.15 (April 2020)

     

    Here's a brief summary of the steps:

     

    1. Create and save an empty server workflow
    2. Sign in to https://survey123.arcgis.com/surveys and create a new survey.
    3. Edit the Settings of the survey.
      1. Add a webhook.
      2. Set the "Payload URL" to `https://server/geocortex/workflow/service/webhook/survey123/{workflowId}?foo=bar` where `{workflowId}` is the ID of your server workflow. Querystring parameters are optional.
      3. Enable the "Portal info" event data (required for secured workflows), and any other event data you like.
    4. Save and publish the survey
    5. Open the live survey
    6. Open the browser's dev console
    7. Complete the survey
    8. Notice the webrequest to the webhook endpoint in the network traffic
    9. Modify your server workflow to do something useful with the workflow inputs. For example, use `$getWorkflowInputs1.inputs.body` with the Write File activity to write the "body" input to a file. There is also a "queryString" input.
    10. Rerun the workflow and observe that the body contains the event info from the webhook request from Survey123.
    11. Disable the "Portal info" event data and confirm that now the workflow must be shared with everyone.

     

    0
  • Berend Veldkamp
    Redigerad

    Ken Lyon Where can we find the swagger documentation for the workflow server rest api? I'd expect it to be here, but can't find anything.

    1
  • Ken Lyon

    Berend Veldkamp If you have an on-prem installation, it's here:
    https://<your-server>/vertigisstudio/workflow/service/specification

    1
  • Claire Inbody

    Hello - I am following this youtube video. I got this to work in 2021 but now with a new version of worklow and reporting its failing to work and my portal version changed to 11.1. Do you know if this still can work? 

    https://www.youtube.com/watch?v=seQiQ1uz3jc

    Reporting Version 5.21.2

    Workflow Version 5.35.0

    Thanks,

    Claire

    0
  • Berend Veldkamp
    Redigerad

    Ken Lyon The link to the specification does no longer work in version 5.53.0.1. The page content has a reference to ./specification/swagger.json which should be ./swagger.json (or ../specification/swagger.json of course)

     

    Also, it looks as if something has changed in the way the endpoint is authorized. If I pass a Bearer token in the Authorization header, the workflow fails and I see this message in the system's event log: System.NotSupportedException: Runtime type 'VertiGIS.Workflow.Server.Documents.JwtDesignerContent' is not supported by polymorphic type 'VertiGIS.Workflow.Server.Documents.PortalIdentity'. Path: $.Identity.
     

    Looking at the specs, it seems that the authorization header does not accept Bearer anymore, and the header value should just be the bare token. So, I'd like to know in which version that changed, so that I can support both options. Or was the version without Bearer always an option?

     

    0
  • Ken Lyon

    Berend Veldkamp Funnily enough, I just created a bug fix for the specification bug now. It seems our specification page pulls in the live “latest” version of a certain package to show the spec. A new version released just under two weeks ago broke the construction of the relative path to “./specification/swagger.json” when the url does not end with a slash.

    In the short term, the workaround is to add a slash to the end of the url and it should load correctly, although now it's in dark mode for some reason.

    On the other topic, we haven't changed the supported authorization options. If we were doing something like that, we'd give advanced notice. Not so long ago we did change the library we use for serialization/deserialization of JSON. It was a very difficult change to test thoroughly as so many things were affected. We keep finding tiny regressions here and there that were caused by it. If this has recently stopped working, that would be the most likely explanation.

    0
  • Berend Veldkamp
    Redigerad

    @Ken,

    The swagger URL is not a big deal. I keep forgetting it anyway, so I have to come back to this topic anyway to look it up ;-)

     

    The other thing is strange though. Our software that starts a server workflow worked earlier this year with 5.49, but after a recent upgrade to 5.52.1 it stopped working. I included the complete stack trace below, and it seems to be JSON related.

    It does work on another machine that has 5.53.01. 

    It also does not work on 5.51.1

    I'm now looking into how our web requests differ from the ones that are used in the Sandbox (which works, of course), but I don't see anything obvious.

     

    Here is the stack trace:

    Exception: 
System.NotSupportedException: Runtime type 'VertiGIS.Workflow.Server.Documents.JwtDesignerContent' is not supported by polymorphic type 'VertiGIS.Workflow.Server.Documents.PortalIdentity'. Path: $.Identity.
 ---> System.NotSupportedException: Runtime type 'VertiGIS.Workflow.Server.Documents.JwtDesignerContent' is not supported by polymorphic type 'VertiGIS.Workflow.Server.Documents.PortalIdentity'.
   at System.Text.Json.ThrowHelper.ThrowNotSupportedException_RuntimeTypeNotSupported(Type baseType, Type runtimeType)
   at System.Text.Json.Serialization.Metadata.PolymorphicTypeResolver.TryGetDerivedJsonTypeInfo(Type runtimeType, JsonTypeInfo& jsonTypeInfo, Object& typeDiscriminator)
   at System.Text.Json.Serialization.JsonConverter.ResolvePolymorphicConverter(Object value, JsonTypeInfo jsonTypeInfo, JsonSerializerOptions options, WriteStack& state)
   at System.Text.Json.Serialization.JsonConverter`1.TryWrite(Utf8JsonWriter writer, T& value, JsonSerializerOptions options, WriteStack& state)
   at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.GetMemberAndWriteJson(Object obj, WriteStack& state, Utf8JsonWriter writer)
   at System.Text.Json.Serialization.Converters.ObjectDefaultConverter`1.OnTryWrite(Utf8JsonWriter writer, T value, JsonSerializerOptions options, WriteStack& state)
   at System.Text.Json.Serialization.JsonConverter`1.WriteCore(Utf8JsonWriter writer, T& value, JsonSerializerOptions options, WriteStack& state)
   --- End of inner exception stack trace ---
   at System.Text.Json.ThrowHelper.ThrowNotSupportedException(WriteStack& state, Exception innerException)
   at System.Text.Json.Serialization.JsonConverter`1.WriteCore(Utf8JsonWriter writer, T& value, JsonSerializerOptions options, WriteStack& state)
   at System.Text.Json.Serialization.Metadata.JsonTypeInfo`1.Serialize(Utf8JsonWriter writer, T& rootValue, Object rootValueBoxed)
   at System.Text.Json.JsonSerializer.Serialize[TValue](TValue value, JsonSerializerOptions options)
   at VertiGIS.Workflow.Server.JsonSerializationUtility.Serialize[T](T value)
   at VertiGIS.Workflow.Server.Foundation.Helpers.Serialize[T](T value)
   at VertiGIS.Workflow.Server.Platforms.FileStore`1.SaveToFile(String key, T value)
   at VertiGIS.Workflow.Server.Platforms.FileStore`1.Set(String key, T value)
   at VertiGIS.Workflow.Server.Documents.JobContext.CaptureAsync()
   at VertiGIS.Workflow.Server.Controllers.JobController.RunWorkflowAsync(String authHeader, RunRequest request)
   at lambda_method43(Closure, Object)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableObjectResultExecutor.Execute(ActionContext actionContext, IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|7_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at VertiGIS.Workflow.Server.Middleware.MainHandler.Invoke(HttpContext context, IOptions`1 settings)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()
    0
  • Ken Lyon

    Berend Veldkamp I just noticed how old this thread is. Just so you know, there's no extra charge for starting a new one. :)

    That stack trace is helpful, as were the versions you mentioned. Actually, I was a bit confused by 5.53.01 as there is no such release, but I got the general idea.

    The stack trace confirms that the failure is related to the change to use `System.Text.Json`, which was made in v5.50. Broadly speaking, the big problem is that `Newtonsoft.Json` was much more permissive with JSON that looked kind of like what it expected. Whereas, `System.Text.Json` seems to need custom code for every single type that something could be deserialized as. It's a real pain.

    The error is happening when you're running a workflow and it's trying to save the job to disk. The problem seems to be that the Identity within the context is of type `VertiGIS.Workflow.Server.Documents.JwtDesignerContent`, which it doesn't like. When I run a server workflow from the sandbox and step through the code, in my case it's of type `VertiGIS.Workflow.Server.Documents.JwtRunContent`. My guess is that you're using a designer token instead of a run token. It's possible that Newtonsoft allowed this in the past because `JwtDesignerContent` is a sub-class of `JwtRunContent`. However, System.Text.Json is more strict.

    Could you try using a run token instead of a designer token and see if that works?

    I can see in our code where I could make this work, however I'm not sure if it would be the right thing to do. The designer never runs a workflow, so it's not expected that a designer token should work for that operation.

    In case you're interested, here are all the regressions related to System.Text.Json that we've fixed so far:

    • 5.51
      • Bug 369247: Error serializing outputs of Server Workflow
    • 5.52
      • Bug 383802: DBNull serialized as “{}”
    • 5.52.1
      • Bug 389529: smallint values from SQL queries get serialized as empty string
    • 5.54 (Not released yet)
      • Bug 398778: Server workflow no longer supports the "Webmap Parameters" input for Run Report activity (The scale input was being deserialized to a different type, and being ignored)
         

     

    0
  • Berend Veldkamp

    Ken Lyon Thanks, the designer token issue was spot-on, and using the /auth/token/run endpoint fixed my problem.

    5.53.0.1 comes from a front page we built for the modules, where /workflow/service/ping is queried to show the current version number. The designer shows just 5.53.0

    0

Du måste logga in om du vill lämna en kommentar.

Hittade du inte vad du sökte?

Nytt inlägg