So now we saw already how we can access information or values of
our variables using the log functionality.
But what happens if the location is a location that is not known,
or we are not having any compute resources at specific locations,
or it's just a value that will not match our environment.
So, then it should not only log out on information,
but it should throw an error, right?
So, let's take a look at how we can achieve that.
So, we again have opened up the PS‑Demo workflow here.
We're still getting the location, and then we want to log out the locations.
So here in the scriptable task or in our scripting pane,
we can now add entries to our script to make sure that whenever a
location is mentioned that is not matching our environment,
then it should throw an error.
Let me just quickly pause the recording.
I'm going to add the entries to the script, and then I'll be right back.
Welcome back!
So I guess you never left, but for me it was like a 1 or 2‑minute break here.
So what I did is I added an if statement and an else statement.
So,
basically this statement in JavaScript is checking
the information where the loc, so our variable,
the value, equals Europe, then it should just put an info,
Location of VM, the same goes for Asia.
But for everything else, so if it's not matching Europe or Asia,
it should say System.error("Unknown location!") So let's give it a try.
I'm going to hit Run.
We're going to say Europe.
It's completed?
We take a look in our log Location.
Perfect.
It says Location of VM: Europe.
But what happens if we run it again and instead instead of Europe,
we are saying USA, for example.
We click on Run.
So, the workflow has completed.
But what happened?
When we take a look at the logs,
you can now see that in the third line we do not have an info anymore,
which says Location of VM: Europe.
It now says Unknown location!
Because USA is not matching either Europe or Asia as input,
right, so it's throwing an error message here,
Unknown location!
And this is one possible way to check whether the information or the values of
your variables are correctly configured by throwing error messages in the logs
here in Orchestrator client by using System.error.
But maybe you not want only to have like an information in the logs,
but you want also that the workflow will fail whenever there
is a value used that should not be used.
So, for example, an unknown location.
So let me show you how you can achieve that.
So we switch back to our edit mode of our schema,
and now we do have again do some changes to our workflow.
Because right now it's just logging out an error message, right?
But the workflow will still be completed,
or even if I'm choosing another location in Europe or Asia.
So, what we want to do is we want to throw a so‑called exception.
So, whenever there is not Europe or Asia mentioned in our input,
it should throw an exceptio so that the workflow
will fail with misconfigured input.
So let me do the changes.
See you in a bit!
Okay, so I did some changes in our workflow.
So, the first step is I've added a so‑called decision element.
So right after get Location, we now do a decision,
and this decision gets log variable as an input.
And down here,
you can see that I've added a JavaScript code which
says if loc equals Europe return true, or if loc equals Asia return true.
So the decision will now take a look at the value of your loc variable.
When it's matching Europe or Asia, it says,
okay, perfectly fine, we're going to follow the green way.
So the green way here would be to the right, and then it says the log Location.
When we go to scripting, I've just changed it back to the first version,
System.log Location of VM, and then the value of our variable.
But when in the decision we will see that maybe the value of our
variable loc is not matching either Europe or Asia,
it will then throw a so‑called exception.
So this element here is called throw exception,
so it's now ending with an error.
And in the exception handling part here,
you have to specify which binding to an output of the element before,
so basically which information should be part of your
exception handling here as well.
So, let's take a look if this works.
So I'm going to hit Run again.
So the location now first is Europe.
We'll click Run.
The workflow says it's completed.
We take a look at the logs, and you can see it says Location of VM: Europe.
Perfect.
So now run it again, and now instead of Europe, we say USA.
And remember the example I showed you before,
it was a completed workflow, but we could find an error message within our logs.
But now we want to achieve that whenever we are using an
input here that is not Europe or Asia, the workflow itself should fail.
So let's take a look if this works.
So we click on Run, and you can see now that the workflow has failed.
Okay, so we reached the decision, and in the decision,
there was acknowledged, okay,
the value of the input of our loc variable is not Europe and not Asia,
it's USA.
You can see it on the right side, it says in the exception handling, it's USA.
And when we now take a look at the logs,
you can see that it says workflow execution stack state failed.
So,
the workflow has failed and the exception is USA because the
value USA is not either matching Europe nor Asia.
And this is one example of how you can work with error
handling or exceptions during a workflow,
run in Orchestrator.
You can choose to just throw an error message in the logs,
or you can even say this workflow should fail when there is some misinformation provided.