nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workflow Manager - Send and Receive Webhooks

COSPNWGuy

It just makes natural sense that Workflow Manager should be able to send out webhooks for integration into other systems as well as receive webhooks so GIS workflows can be triggered. Many workflows spill over into other systems, and webhooks is an ideal and uncomplicated way to address this continuity challenge without having to implement a full-on integration project. The news during UC 2020 that Workflow Manager will be becoming all services based makes this an ideal platform for webhook integration.

Encontre mais publicações marcadas com

In Product Plan

Status: In Product Plan

Comentários

COSPNWGuy

Just wondering what the status of this is. Has this been implemented?

Anonymous User

@COSPNWGuy

Very good. We'll see how we progress through this next release and what we're able to tackle but I will follow-up more in the future. 🙂

Cheers,

Michael

COSPNWGuy

Hi @Anonymous User. Here are some use cases.

Directly we would integrate with the following systems (and use cases) as of this time:

Monday.com - We use Monday.com as a task and resource management system for my staff. Staff record all assigned tasks and note progress here. A large amount of the work we do is GIS, so having a link between the two systems makes it easier to automatically track GIS workload without manually entering it into Monday.
Skyward.io - We use Skyward as our drone (fleet) and mission tracking platform. However, we use the GIS to record where clients want drone missions to occur. Linking these two systems together via web hooks allows a seamless continuity of data from mission request all the way to mission completion.
Microsoft Power Automate - We are a Microsoft shop with innumerable workflows build on top of Microsoft products. Power Automate allows us to easily "stich" not only Microsoft products together but many other external systems right out of the box (Survey123 is supported out of the box). It also can send and receive webhooks making it extremely flexible. Our GIS system is part of many of these Microsoft "heavy" workflows, however we have to rely on manual\human intervention for to connect the GIS to the rest of the workflow.

Hope this is helpful.

Anonymous User

Hi PNW,

There are no emojis it seems in this system or I would 'heart' your response.

You'll be happy to know we've dipped our toe into handling web hooks at 10.9. There will be a new ability to receive the Survey123 web hook and have it create a Workflow Manager job. Customizable functionality and parsing will be things we will consider at later releases, your ideas are very pertinent to those discussions though and inline with some of our own thinking.

You mention specific behaviors for webhooks, but could you list out specific systems and use cases that you're trying to integrate with. That will be very helpful in our analysis if we understand more of the use cases. 🙂

Thanks!

Michael

COSPNWGuy

Hi @Anonymous User,

This is great news! And I do have some ideas! I also posted a hypothetical workflow on this idea: Allow AGO and Enterprise to be a Webhook Receiver. We integrate between may different systems including other SQL and Oracle databases and online work management tools such as MS Flow, Monday.com and Smartsheets.com. I know that Integromat and Zapier are really popular too, but I don't have direct experience with those.

So three main ideas:

It would be wonderful if the webhook payload contents could be somewhat defined by users (for webhooks going out of Workflow Manager), rather than just a one size fits all schema. Perhaps a standardized or "recommended" json object could first be presented, but allowing flexibility on what to include in the payload adds a ton of value. I have seen this done really well by GUI's that allow the user to pick (or omit) which fields or other data from the object they want to include. The reason for this flexibility is really to streamline the parsing on the receiving side. Including only relevant data not only helps the json be more efficient, but can streamline and clarify communication between the people and teams representing the systems involved. The destination system might be handled by a completely different group of people that those managing Workflow Manger.

The second idea is related to incoming webhooks to Workflow Manager. There should be a tool where you can paste a sample json object from the origin system which will auto-parse the object for the user and decipher fields of data within the object. (Microsoft Flow has this ability for example and makes it super simple to use the resulting data.) These data fields could then become available in Workflow Manager to perform other tasks\logic against.

And the third idea is really to spoon feed security between systems. (This is more of my point of view, rather than a idea.) It should not require a IT Networking guru and a dictionary of Networking terms to get a webhook into Workflow Manager nor get a receiving system to recognize a webhook from Workflow Manager as legit. (It seems like tokens is usually the authentication measure used most often in these APIs, so it should overall be really easy to generate and manage tokens.)

I have noticed that a what sets apart these kinds of integration systems from "lousy" to "great" are those that really take the complexity out of the json objects as well as spoon-feeds setting up the authentication between systems. In my opinion, if you alleviate the "pain" in these two areas, users will be able to spend more time on optimizing workflow problems rather than spending hours trying to get systems to "talk" or interpret json. Offloading the json parsing and authentication onto the user without any help (which I have definitely seen in other system "integration" products) comes off as lazy and diminishes why a org might invest in that solution in the first place. It has amazed me over the years how many software "solutions" have done nothing for me but add more complexity because the vendor didn't want to do any heavy lifting. Not saying that ESRI would ever do that btw.

Looking forward to seeing these capabilities come to life!!!!

Anonymous User

Hi PNWGuy,

Thanks for your contribution. This is in our product plan for the new service-driven architecture. Both from the side of being able to send web requests driven through the workflow or by the system, and receiving webhooks that can be ingested into Workflow Manager actions.

We're in the planning stages now to start work on this in 2021, so if you have any use cases or requirements you'd like to pass on please do 🙂

Cheers,

Michael

Participe da Conversa

Faça login para postar, seguir conteúdo e mais. Novo aqui? Registre-se gratuitamente.