Best Practices for Building a Workflow that Works in Multiple Environments [Geocortex Tech Tip]

Have you ever designed a workflow that you want to use in different environments? Geocortex Workflow offers a capability to create flexible workflows that can run in multiple environments – a functionality that saves time and reduces development requirements!

This Geocortex Tech Tip explains how to create and configure workflows that can be used in multiple environments and easily migrated from one environment to another. Additionally, it demonstrates the process for testing a single workflow in various environments to ensure that it works correctly in each one.

Watch on YouTube.

Video Transcription:

Hey everybody, my name is Patrick Fingler. In this Tech Tip video, I’m going to provide an overview of how to architect your workflows so that they can work in different environments. For example, you might want to build a workflow for Web AppBuilder that also works in Geocortex Web. I’ll provide some tips and tricks for this process. An overview so you can get started. Let’s dive in!

Alright, so if you’re wanting to design a workflow that can work in different environments or just engineer your workflows so that they’ll be a little bit easier to migrate from, for example, Web AppBuilder to Geocortex Web or eventually Experience Builder, our “Create Workflows that Can Run in Different Environments” document is something that I’d highly recommend reviewing.

If you navigate to the “Geocortex Workflow Documentation Center”, you’ll see here that there’s a bookmark called “Run a Workflow in Different Environments”. This is where it’s going to explain some of the best practices for designing your workflows to ensure that they’ll work in different environments.

Number one in the document says, “Declare the Environment”. In the Workflow Designer you can specify the viewer or Web GIS client that you plan on running your workflow in. This will filter what activities are available to ensure that you’re only using activities that will work in your viewer.

Number two says, “Use Activities Instead of Expressions”. If you’ve been working with Geocortex Workflow, you’ll likely have found that you can retrieve a lot of different objects by kind of dotting into them. “geometry.getExtent()” would be an example of dotting into something where you can retrieve an object by just adding in dot properties.

Now one thing to be aware of is those properties can change whether you’re using the 3.x JavaScript API like in Web AppBuilder versus the 4.x API in Geocortex Web. That’s because the JavaScript API as well as the .NET runtime in mobile have different properties and methods and functions that are available.

So, one thing we can do is use our activities, which have been engineered to work in these different environments, rather than dotting into these objects. I’ll be showing some of this throughout this video.

Lastly in the document it says, “Use Auto-Complete Suggestions in Expressions”. Anytime you’re dotting into an object we’ll typically give you some options that are available. Those options have been engineered to work in all our environments. So, we’ll only show you options that will work in multiple environments.

There are also some other tips and tricks that I’ll be highlighting in this video as well.

So, to get started we’ll navigate to the Geocortex Workflow Designer. You’ll see we’ve added this option here at the start where you can declare the WebGIS client or viewer that you plan on building this workflow for.

You can build it for an individual viewer by selecting “Workflow for Geocortex Web”, “Workflow for ArcGIS Web AppBuilder”, “Workflow for Geocortex Mobile” or “Workflow for Geocortex Viewer for HTML5”. Or you can kind of combine them by selecting something such as “Workflow for Geocortex Web & Geocortex Mobile”.

Additionally, you can click “Choose Environments”, and this is where you can customize the workflow and build a workflow that will work in all your selected environments. I’ll select “Choose Environments”, and after selecting my environments, ’ll click “Create”. This will then take us to the Workflow Designer.

Here you’ll see its filtering the activities that are available. You can also adjust it. So, maybe we’re only interested in building this for “Geocortex Web”, “ArcGIS Web AppBuilder” and “Geocortex Viewer for HTML5”. You’ll see here now we’re only showing you the particular activities that will work across all three platforms.

Now let’s choose an activity like the “Get Portal User” activity. This works across all three environments. If I wanted to get the usernames of who’s logged into my application, we could add an “Alert”. Then we can set the title of this to be “User”. When I click on “Text” it will open up the “Input Editor” and I can start writing an expression.

I’ll find my “Get Portal User” object and add a period. Some objects and properties will appear. And we know because we’re seeing this autocomplete that it’s going to work across different viewers. So, if we select “user” this will always return the user whether you’re using it in Web AppBuilder, Geocortex Viewer for HTML5 and so on.

If I add another period and dot in again, you can see that there’s all these properties that appear and these will always work across all the different viewers.

So, if I want to get the username I’ll select “username”. And I’ll click “OK”. I’ll save and run. We’ll call this “Tech Tip Username” and click “Save”.

I’ll go to “Info” and click “Run in Sandbox”. Let’s open up the console here and I’ll just clear this. If I click “Run Workflow” we should see that it has retrieved my “User”.

If we look into the “GetPortalUser” activity we can see what the outputs are. This is our “user”, and if we scroll down, we can see “username”.

And maybe now I want to get the credential, or token, of this user. Here we’re running this in our 4.x environment so we can see here there’s this dot “portal” property under “user”. We didn’t present this option when you were using your activity, so let’s just expand “portal”, scroll down, and we can see here there’s “credential”. If we scroll down again there’s “token”.

So, now we’re starting to dot into the object. When you start doing this you could run into issues when you’re migrating from one environment to another.

Here in our workflow, I can use the approach of “user”-> “portal” -> “credential” -> “token” to get the “token”. Let’s add an alert here called “Token”. So, our expression previously ended with user and now we’re kind of going rogue here and we’re going to add to our expression. We’ll add “portal.credential.token” to get the token. So, our expression in the “Input Editor” should now say “=$portalUser1.user.portal.credential.token”. Let’s “Save” that and rerun it in our sandbox.

I had the user and now I’ve got the token.

If I try running this in our 3.x environment, this is where you might run into issues. We’re now running this in the 3.x JavaScript API. Let’s run it. We’re getting the user. But there’s an error. It’s not getting the token. That’s because if we look at the outputs of our “GetPortalUser” activity here, you can see there is no credential object on the portal feature here. There’s no credential being indicated. That’s because the way the 3.x JavaScript API works is that there’s a credential property that’s just a level up and above it. So, if I wanted to get the token, I’d have to add “user.credential.token” to our expression.

So, let’s go back to our workflow and I can modify this. Let’s remove the “portal” from our expression in the “Input Editor” and we’ll re-run it. I’ll save this and now we should get the token.

But now what if I want the same workflow to work in multiple environments? This is where you might need to do some branching. To do some branching, I’d recommend using the “Get Application Info” activity.

Let’s just move our workflow over a little bit.

Now this will give you the name of the application. This is where you can do a “Switch”. So, you’ll specify if the application is in Web AppBuilder, or if it’s in Geocortex Viewer for HTML5 and so on. For the “Value” on the left we’ll say, “=$appInfo.name” and then we can do some branching. For example, we can tell our workflow that if it’s Web AppBuilder, or the 3.x JavaScript API, then use the token approach “user.credential.token”. But if it’s Geocortex Web then let’s use the “user.portal.credential.token” approach where the portal option has been appended.

You’ll probably want to write this like a variable for your token. But let’s save this and run this workflow in Web AppBuilder and Geocortex Web just to confirm.

So, here I’ve got a Web AppBuilder application. Let’s go to the “Widget” tab and add our workflow. I’ll add our “Tech Tip Username” workflow into Web AppBuilder.

Then let’s go to Geocortex Web and add that same workflow to our “I want to…” menu.

Then we’ll run this. I’ll go to the “I want to…” menu in Geocortex Web and select our “Tech Tip Username” workflow. You can see it’s getting the token in Geocortex Web. And here in the console you can see that there is this “GetApplicationInfo” where it’s outputting the name of my application as “GXW” which is Geocortex Web.

Then we’ll go to Web AppBuilder and run our workflow. You can see we’re getting our token. If we look at “GetApplicationInfo” in our console it says “WAB” so it’s properly getting that token.

That’s just a quick overview of some tips and tricks for designing your workflows to work in multiple environments. Bye for now!

Want to learn more about the capabilities of Geocortex Workflow? Click the button below for more information on what is possible with Geocortex Workflow.

Discover Geocortex Workflow