Re: [cacao-comment] Sharing Playbooks and Schedules

On Fri, Dec 13, 2019 at 1:37 PM Allan Thomson <athomson@lookingglasscyber.com> wrote:

Toby â thanks for this email. I think you should add this information to our use case document on google. Let me know if you donât have access to that document yet.

Â

Hereâs some requirements/outcomes that I gleamed from your writeup.

Â

Scheduled application of an appropriate playbook.

I believe we have this in our requirements document already and planned to make sure the schema supports scheduled execution.

Execution of a secondary playbook after the completion of a prior event/trigger/playbook based on a delta (not absolute schedule).

Same answer as 1) we have that in the requirements and planned to include this as part of the playbook action steps.

Variable based definition within a playbook for specific environments allowing a template playbook to be defined but without concrete absolute/assigned values for certain parameters.

This is requires both template playbook definition plus the ability to reference variables that are assigned when a template playbook is translated into an executable playbook.
Our intention is to support this for a variety of good reasons as you have highlighted.

Language definition and capabilities are important

Defining a schema/playbook language that leverages best practices (such as BPMN) but focusing that language on the key requirements rather than being strict is our approach so far.
Our path so far has been focused on solving the problems we need.

Â

In general, I believe your examples are great background/justification on what we are trying to do with CACAO and personally I feel weâre on the right path towards solving them.

Â

regards

Â

Allan Thomson

Â

From: <cacao-comment@lists.oasis-open.org>, Toby Considine <tobyconsidine@gmail.com> on behalf of Toby Considine <Toby.Considine@gmail.com>
Date: Thursday, December 12, 2019 at 8:31 AM
To: "cacao-comment@lists.oasis-open.org" <cacao-comment@lists.oasis-open.org>
Subject: [cacao-comment] Sharing Playbooks and Schedules

Â

As part of the national smart grids project, I was part of many discussions about scheduling complex sequences of behavior. As these seem to match quite well the playbook scenarios as I understand them, I am sharing these issues with CACAO.

Â

Consider a playbook we all have experience with, a conference. A date and times are published. Call this the active period.

The Conference staff have an existing rule to being check-in 90 minutes before the conference. They also have a rule to be on-site for after a conference. They also know that they should be on hand a half-hour before check-in begins.

The conference security group knows to unlock the doors to the public when check-in begins, and to lock them at the end of the post-conference period.

The set-up crew needs to arrive two hours earlier still to set up the booth, and to have access for one hour later to break down and pack the booth. One security agent must be on hand to let them in and out.

Reaching out a little further, the conference staff support needs to have all travel needed, if any, booked two weeks before the conference, with special rules for booking travel for Monday AM conference (all booked by two Fridayâs before). Travel might or might not include an overnight stay dependin upon how late in the day the conference ends. They also are scheduled to get all expense reports completed by one week after.

Each of these schedules involves different Actors, responding with their own calendar off-sets based on different business rules. Special circumstances such as lead-times for notifications during business hours as well as for after business hours need to be factored in. Business schedules need to be factored inâis Saturday a regular business day or not for *this* entity.

In our requirements, scheduling the conference from 9-1 onÂ Tuesday would trigger the correct playbook for each of these entitiesâand the implicit offsets might be entirely different for 9-2 on Monday, or for 9 11-4:30 on Friday. The only thing the scheduler would consider is the conference time.

Â

These are the types of scenarios we worked for the National Smart Grid efforts. There were also different response-time scenarios based upon notifications. For example, Automated Demand Response, a willingness ot use less electric power upon request may need business approval. AN entity may promise to respond upon a half hourâs notice during business hours, but require an hour after hours. But what are business hours for *this* organization. Do they include a half-day Saturday? Are they adjusted for Daylight Savings time or Not?

We also faced smart energy requirements for schedules independent of absolute time when describing smart buildings. For example, one national Energy Manager defined a common set of heating and cooling schedules for a national chain of stores. Heating and cooling would change a half hour before 9:00 opening, and change again at 6:00 closing, whatever time zone the branch was in.

Every calendar event is fully described by a Begin Time, a Duration, and an End Time. Conformance needs any two, to compute the third. We defined a mechanism of inheritance, so a complete playbook (as above, the conference time above) could be predefined, and by applying a start time and duration for a single interval (the conference time), all other intervals could be computed. The computed intervals can then be transported directly to 3rd party organizations using well known mechanisms and transports.

Â

We chose to build are communications around the well-known semantics of iCalendar (RFC 5545), because all these activities are ultimately linked to the activities of people. The Calendar guys in the IETF (the CALCONNECT organization) augmented some existing work into the Availability object (RFC 7953), which is ideal for expressing notions such as Business Hours. We defined overlay rules for Availability and Unavailability, so that the six week summer shutdown could overlay the regular Availability.

Actual tasks were then considered to be domain-specific payloads within each calendar object.

We defined standard information objects to link calendar events. Events might be handled as following in short order, or starting no more than 6 hours after another, or even beginning 10 minutes before another ended. These sequences are understood by a growing number of calendar servers, and there is some open source code available. Icalendar serialization is already defined for XML (XCAL) and JSON (JCAL) and Restful interactions are defined for each.

Â

So coming back to CACAO, this model enables a playbook of considerable elaboration to be specified by a single directive âbe in most restrictive mode during non-business hoursâ or âstay in lockdown for 72 hoursâ and still have numerous activities within, before, and after the significant period.

Â

For smart energy, we did not find BPEL to be flexible enough to handle these sorts of directives. If there is interest, I can jin the TC, and explain the uses of WS-Calendar, the OASIS standard for M2M negotiation of human-centric Schedules. If CACAO opts to use these semantic models, it should likely be based on the abstract WS-Calendar Platform Independent Model (PIM) which abstracts much complexity and potential recursion from the raw RFC 5545 formats.

Â

tc

cacao-comment message