This is the second article in the Definitive Guide series. This time we take a look at the ability to Schedule an Orchestration integration within ICS has arrived with release 16.4.5 release of ICS, To demonstrate this, we are going to reuse our FlightSitRep endpoint from the book’s Chapter 3. If you have not got the book yet – it’s a WSDL one way integration that is connected to Mockable.io.
Creating Scheduled Orchestration
From the Integrations screen we need to click on the New Integration button, and select the Orchestration pattern in the pop-up dialogue. The first thing we will see when creating an integration is the Create New Integration dialog, as shown here:
As you can see the dialog has a new toggle option which defaults to represent the common approach to Orchestration, that being event triggered through an event or object defined by a connection.
We can configure the integration’s initial properties with the following values:
|Identifier||This will be proposed based on the connection name and there is no need to change unless you would like an alternate name.|
|Description||Calls the flight SitRep endpoint, but is triggered by the scheduler|
|What triggers this integration||Select the Schedule option|
The all-important thing here is the last line in the preceding table. We have changed the new option to set the trigger to be the Schedule option. With these values set we can complete the step using Create button. Once the integration has been created, we now see a message displayed in the message bar near the top of the screen.
With the creation successfully completed, can now see and interact with the standard Orchestration (Chapter 10 of the book goes into detail) canvas. Unlike the normal canvas start state we do see a difference. The initial trigger spot, is populated with the scheduler icon. This is illustrated in the following screen shot:
Before we look at the scheduler in more detail, we need to complete the rest of the integration.
Adding a Target
Grab the FlightSitRep_Ch3 SOAP connection from the Invokes list of SOAP options and drop it onto the canvas as you would normally do for an Orchestration. This will launch the relevant endpoint wizard. We would suggest completing the wizard with the following information:
|Basic Info||What do you want to call your endpoint?||ReportSitRep|
|What does this endpoint do?||Invokes our flight sit rep Mockable stub|
|Review updated SOAP adapter runtime||Toggle to No|
|Operations||Selected Service||As our WSDL is very limited, we do not get any options on this tab, and the options completed for us should be:
With the wizard complete, and the Summary tab showing us the expected details we can complete the wizard by clicking the Done button. The canvas is then updated accordingly, and now includes in the flow a spot for defining he mapping.
Mapping the Scheduler Values to the Target
Click on the mapping spot on the canvas to open the Mapping editor. Which will look like following screen:
Note how on the left hand-side as the only source of information is from the scheduler. As the scheduler is also a key element for file and FTP processes the filename attribute is exposed. However, the important attribute for us is startTime which will always contain the time the trigger occurs.
On the right-hand side, we see the elements from our WSDL. As some of these are mandatory, for simplicity we will hardwire the values. But we will also map startTime and filename so we can see their values. We would recommend setting up the following mapping:
|–||faFlightID hardwired to “1”|
|–||ident use the generate-guid function (Mapping Components | Functions | Advanced)|
|–||prefix hardwired to “BA”|
|–||type hardwired to “A320”|
|–||suffix hardwired to “123”|
|–||destination hardwired to “LHR”|
|–||longitude hardwired to “0.0”|
|–||latitude hardwired to “0.0”|
With the mapping complete we can close the Mapping dialogue with the Done button. The integration to demonstrate the scheduler is pretty much complete, The canvas should appear as shown in this screenshot:
The last thing is to set the Tracking up and we will use the startTime as the tracking attribute. We can also add the fileName for convenience, as you can see in the following screenshot:
Setting up the Schedule
What we have not obviously done is set the scheduler. This is because the scheduler works exactly like the file and FTP driven integrations. Where we set the scheduler up when we are ready to Activate the integration. In fact, the scheduler steps are exactly the same as those when we demonstrated the FTP integration in Chapter 9 of the book.
This means we can create schedules with the following kinds of characteristics:
- One off events at a defined date and time,
- Events that occur a number of times and then stop or run indefinitely,
- Events can be based on period intervals of no less than 10 minutes.
- Through to days on a month and so on.
The following image illustrates one option:
Advanced Schedule Configuration
In addition to the menu driven selection of when an integration can be scheduled, it is also possible to define the scheduling using the iCAL format. This is done by pasting into the Advanced view the iCal definition according to the standard. Understanding the iCal format is worthy of its own blog posts, so we won’t address it here.
For monitoring of the integration, this is no different to monitoring a scheduled file transfer integration. In fact, the monitoring makes no difference when it comes the integration patterns in used.
With the integration activated, and the Schedule running we will see in the the calls arriving in Mockable.io. The ICS Monitoring views views will also show us what is being triggered.