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:

create new orchestration wizard

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:

Property Values
Integration Name FlightSitRep_DG2
Identifier This will be proposed based on the connection name and there is no need to change unless you would like an alternate name.
Version 01.00.0000
Package Name ICS.BLOG.DG2
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:

Tab Question Answer
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:

FlightUpdates

Selected Port FlightUpdatesSoap
Selected Operation FlightStatusUpdate
Request Object FlightInfoUpdateMsg

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:

mapping editor for our orchestration

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:

Source Target
 – 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
startTime timeout
startTime timestamp
longitude hardwired to “0.0
latitude hardwired to “0.0
filename updateType

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:

orchestration canvas

Tracking

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:

tracking identifiers in orchestration

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:

Scheduler set and showing future executions times

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.