How to use the Scheduler node in IBM App Connect Enterprise 12.0.9.0

Aug 24, 2023

How to use the Scheduler node in IBM App Connect Enterprise 12.0.9.0

In this video, we demonstrate how to use the Scheduler node that was added in IBM App Connect Enterprise 12.0.9.0 with examples of the functionality aspects.

Content

0.24 -> Hi, I'm Sanjay Nagchowdhury, Development Lead for the IBM App Connect Enterprise product.

5.52 -> In this video, I will demonstrate how to use the Scheduler node. The node was added in IBM

11.58 -> App Connect Enterprise version 12.0.9.0. So I'm showing the documentation page

19.02 -> here which describes the new function that was added in the mod releases.

23.46 -> And in version 12.0.9.0 we provided the Scheduler node.

28.38 -> It's fully documented in the IBM documentation and in the documentation topic,

34.56 -> you can see how to configure the node and see the different node properties that are needed.

40.38 -> So I'm going to describe how to use this node, let's take you through a

46.26 -> couple of aspects of the node. The first is that you need to

50.22 -> configure when the flow should be run. So it can either be run at specific

55.86 -> intervals such as every 2 seconds or every 10 minutes or it can be run on specific dates and

63 -> times such as every Tuesday at 11:45. The second aspect that you need to

69.6 -> configure on the node is that what should be propagated from the Scheduler node itself,

75.3 -> it can be one of three things. By default, it can be a JSON message

80.04 -> and the JSON message that is propagated has a consistent format with a message

85.44 -> that is propagated from the Scheduler node that you might be using in Designer flows.

90.3 -> So this allows you to use the Discovery Connector nodes in the message flow with a Scheduler node.

96.78 -> And you will see if it has the same behaviour as Designer flows.

101.04 -> The second option is to use the same output message as the one that is

105.54 -> propagated from the Timeout Notification node. So this allows you to migrate from the Timeout

111.48 -> Notification node to using the Scheduler node. And the third option is to use a user defined

117.3 -> message which means that a Compute node is not needed downstream to update the message body.

124.02 -> You can specify the message body in advance without needing a Compute node.

129.66 -> I'm going to describe some of the differences between the Scheduler node and the Timeout

135 -> Notification node and Timeout Control nodes. First of all, the Scheduler node

139.68 -> has no external dependency. You may have existing flows which are using

144.12 -> the Timeout Notification and Timeout Control node and you would have had a dependency on using MQ.

150.36 -> The Scheduler node does not require MQ. It is built on native code.

154.74 -> So there's no reliance on Node.js or a JVM. If you want to optimize the start-up time of

161.34 -> the integration server so that it turns off using Node.js or JVM, you can do that and still use the

168.18 -> Scheduler node. The Scheduler node can specify an interval and that interval can be in seconds,

174 -> minutes and hours but the Timeout Notification node only supports seconds. A Calendar date

181.02 -> and time can also be specified on the Scheduler node which is not available on the other nodes.

186.06 -> The Scheduler node also has support for running in a specific time zone and has an option to

192.84 -> specify whether a message should be sent to the flow when the message flow is first deployed,

199.08 -> which is not available on the other nodes. Let's go through some examples of

205.8 -> using the Scheduler node. I have a flow here which is

210.06 -> using the Scheduler node, the Scheduler node is in the Timer draw in the Toolbox section of the

216.48 -> pallet in the message flow editor, I have a Scheduler node wired up to a Trace node.

225.3 -> And I'm going to specify to use an interval of every 20 seconds and it will propagate

232.68 -> the message using the default Scheduler format which is specified on the output message tab.

242.28 -> The Trace node is writing a file to a file in the TEST_SERVER directory.

248.34 -> I'm just going to clear out the file and save the message flow, then let's deploy it.

260.04 -> And if I open the file, you could see that straight away a message has been sent to the flow.

269.52 -> And this is because of the Scheduler node I'd specified the option to send a message into the

276.78 -> flow when the message flow is first deployed, it's configured to send a message every 20 seconds.

282.12 -> So if I refresh the flow, I can see that another message has been sent to the flow.

288.36 -> The JSON message that is sent contains the last event time and the current event time.

293.88 -> If I'd specified a Schedule Identifier, then that would have been in the JSON message as well.

300.36 -> I will give a demonstration of that shortly. Let's stop this and use the other

307.68 -> mode which is Calendar. So let's specify Calendar.

311.94 -> The time is currently 5:11. I'm going to say let's run it every day

321.9 -> at 14 minutes past five.

328.26 -> Let's save that. And now let's deploy

332.46 -> that to the flow and let's open the file. So here you can see that the message was sent.

343.08 -> And if I open the web browser, then if I look at the flow and look at activity log,

352.74 -> I can see when the next message is scheduled to be sent into the flow so it will be sent at 5:14.

363.72 -> So it's now 5:14 I look at the file

367.5 -> I can see that I've received a message now at 5:14.

373.32 -> OK. So that was

375.06 -> using the Calendar mode let's stop that

378.06 -> let's show how to use the Identifier and why you might want to use the Identifier.

385.98 -> Let's go back to using interval and let's leave it 20 seconds.

390.18 -> Let's specify an Identifier of say demo every 20 seconds, save that.

398.1 -> And let's add another Scheduler node,

403.02 -> let's specify an Identifier of demo every 10 seconds and change the interval to 10 seconds.

414.84 -> I can wire this up to the same Trace node. And what this means is that when you have nodes

422.28 -> downstream in your flow, you can do different logic in your flow depending on which Scheduler

429.06 -> node propagated the message so you may want to do something different for the different messages

435.24 -> that were emitted from the Scheduler node. So if I deploy this

446.4 -> and scroll down, you can see that on deployed we've got this message here

451.56 -> you can see the Scheduler identifies where it has demo every 20 seconds.

455.46 -> And there's another one from the other Scheduler node which says

460.56 -> demo every 10 seconds in the Identifier. So I would expect another message to be

467.46 -> shown for the thread, which picked up the message for every 10 seconds, so if I update the flow,

475.32 -> you can see that there was another message that was sent after 10 seconds and then both

481.92 -> nodes sent in the message after that as well. So this might be handy if you have specific

489.18 -> messages to be sent at specific times and you want to handle that differently.

493.68 -> And you can do that by using the Schedule Identifier. You may want to migrate from

499.86 -> using the Timeout Notification format and you can do that by specifying to use that

506.04 -> format in the output message tab of the node. So if I select Timeout Notification node format

513.12 -> here, and let's just clear the file so that it's easier to see. If I now deploy the flow again,

526.98 -> the message that's propagated when using the Timeout node has an empty message body,

533.64 -> but has a properties tree only that is showing.

540.12 -> If I look at the message itself using the flow exerciser,

546.06 -> then you can see that it only has a properties tree under the message tree.

552.72 -> And in the localEnvironment, you can see that there is a section for Timeout

558.06 -> Request as well as Scheduler. So this allows you to migrate

562.44 -> your flows from using the existing Timeout Notification node to using the Scheduler node.

569.16 -> Finally let's look at the third option in the output

573.6 -> message which is to use a message assembly file. So you need to specify a message assembly file.

579.12 -> I already have one so I click browse, I can select my message assembly.

584.28 -> If I open the file, you can see that it has some JSON data under the message tree.

592.02 -> So specify first name Sanjay, last name Nagchowdhury.

596.52 -> And if I save that, let's delete the entry should output dot file.

606.36 -> If I deploy this message flow to the integration server and look at the output, you can see that

614.82 -> it's using the message tree from the message assembly that I had specified on the node.

621.42 -> So this means that you don't need a Compute Node downstream to update the message,

627.36 -> you can just simply specify the message assembly to be used in

632.82 -> advance and configure the node to use that message assembly.

640.68 -> The nodes can be overridden through BAR overrides. So if I open the BAR file,

650.94 -> you can specify the different node properties as BAR overrides.

658.32 -> So in this video, I have demonstrated the Scheduler node that was added in 12.0.9.0

663.9 -> The basic tab has options for you to specify an interval or a Calendar date and time.

670.62 -> The type of output message can be specified using three different options,

673.92 -> a Scheduler format or a format which is the same as the Timeout

678.24 -> Notification node or using a message assembly. The activity log has activity log entries and

684.6 -> they can be viewed and BAR overrides can be specified for the different node properties.

Source: https://www.youtube.com/watch?v=mDZt0t9Noyg