Runs, cycles, and bundles walkthrough

Transcript

The purpose of this walkthrough exercise is to clone one of our previously built scenarios and change the number of runs, cycles, and bundles process per cycle. We’ll go into the execution history of our scenario and look at the details of that execution. Here we’ll look at how cycles and bundles are processed as we run our scenario in real time. To prepare for this walkthrough exercise, you only need to find your sharing variables between routing paths scenario previously built.

Let’s start this practice exercise by cloning our sharing variables between routing paths scenario.

We’ll call our new scenario, Sharing variables between routing paths - Cycles test.

We need to make a few changes before we start. Since we’ll be running this scenario multiple times, let’s go ahead and remove the send and email module.

No sense flooding our inbox. Next, I’ll left-click in my trigger module.

I’m going to change the maximal field from 200 to five. Meaning every time this scenario is run, it will process five bundles or five current projects. We’ll also want to scroll down and delete our second filter. So we’ll process all current projects and click Okay.

Next, I’m going to go down to my toolbar and click the cogwheel scenario settings.

And I’m going to change my max number of cycles from one to three. Go ahead and click Okay.

What I’ve effectively done is set up my module to run three cycles per run. And then in each cycle, I’m going to process five of the current projects in my test drive. Next, we’re going to click on the clock island on the trigger module. And we’ll change the default time from 15 minutes to one minute. The lowest you can go. Notice that there’s an advanced scheduling section here where you can schedule your scenario to run on certain days or in certain timeframes.

And we’re going to go ahead and click Okay. And for the first time since starting this training, we’re going to actually activate the scenario to run on the schedule we established. You can do so now in your toolbar by clicking the On in the scheduling slider.

Now, let’s return back to our scenario overview page by clicking the arrow at the top left corner of our designer.

Yes, we definitely want to save this. And then we’ll click on the History tab at the top. Here we can see how the executions are run in real time. You may need to refresh the page here and there.

Here we can see our first successful execution that happened after I saved a scenario.

We’ll click on the Details button to see how our cycles were executed. In the simple log on the right-hand side, we can see that cycle one was started when the execution began.

We can see successful and unsuccessful operations throughout, which is expected based off of our filters.

If I scroll down a wave, I’ll eventually come to where cycle one was completed for the first five projects and cycle two was started. I can continue to scroll down and see all three cycles that occurred.

It’s also important to note that at the top right-hand corner, I have a dropdown to choose which cycle I want to examine in the designer window.

Going back to the top for the first cycle, notice how the module on the left shows up when I hover over it in the log.

This makes it easy to trace our execution. So for the first run, we can see that we found a project in our search. And the next module was going to read a record to find the sponsor name, but it didn’t execute because the filter blocked it. There was no sponsor for the first project, but then we still dropped down to our next path and performed a get variable. If we had left or send an email module in place, we would’ve sent an email with no sponsor name, something we didn’t want to do. So this execution review has helped us see that we need to fix something in our scenario design. -