Declarative Scripting Made by ESI
This document explains the principles of Declarative Scripting support, being
part of the overall ESI ecosystem. We will also refer to
ESI Rails or
which is also the required prefix for any ESI Rails library added to this
We quote the Wikipedia article about the famous Ruby on Rails programming language, in order to emphasize on the key concepts:
[…] Rails emphasizes the use of other well-known software engineering patterns and paradigms, including convention over configuration (CoC), don’t repeat yourself (DRY), and the active record pattern.
The active record pattern plays no role in an inmation environment, as we
(luckily) interact with native in-memory objects instead of database tables. CoC
and DRY instead are very relevant for the
This software engineering pattern is explained
here. We could also
translate it with "Fast, reliable and repeatable results instead of highest
flexibility". The flexibility we sacrifice is still available by using barebone
common esi script style in places where a higher degree of
flexibility is required, or no matching
esi-r library exists. Due to the fact
that most inmation systems are running in an industrial context,
Speed-to-Production and reliability are very important aspects. Another
advantage of keeping the complexity low is that external code generators can be
written very quick, so that system:inmation users may enter the next level of
automation. The "repeatable" aspect is also of highest importance, as large
industrial environments usually have "things" to which software logic can be
applied, by the hundreds, thousands and even higher counts.
This software engineering pattern is explained here. The DRY paradigm protects developers and engineers to invest their precious time into the wrong thing. Who wants to be in the world of WET programming, commonly known as "write everything twice"? Seriously, I was there myself. Too often. Let us all be DRY now.
In the following section, we list the benefits and the requirements
brings with itself.
esi-r libaries implement ready-made scripts for particular use cases. Such a use
case can be: - Configuring 1000 assets in one go from a metadata
I/O Model onto the enterprise:inmation dashboard system, linking it
with the 1000 corresponding data points and have provided dozens of users with
the right data views in seconds. - Fetching a time series record from an
external plant historian and do some statistical analysis on it, then write the
result back to one or many inmation objects for historization purpose - Reading
out actual batch records from an underlying system of different types and
delegate it to some specific complex data processor in system:inmation (which
esi-r, but must not)
esi-r scripts (scripts using
esi-r libraries exclusively) must be written in
what we call the "typewriter mode":
There is one top-down flow
There are no separate functions whatsoever
There are no branches, no if, no then, no else
There are no loops, no repeat, no while
There are esi-r libary calls exclusively
Non-adherence to one of the five rules above is always possible, but then the
script is not considered to be
esi-r. No excuses.
There is a long list of benefits:
esi-rscripts share the same error handling, which includes logging, E-mailing, table staging and notifications through the enterprise:inmation dashboard system (in case of any failure)
esi-rscripts turn simple
GenericItemsinto full-blown use case objects, supplying historized variables for performance tracking, configurational control etc.
esi-rscripts are self-explaining to a very high degree
esi-rscripts are written in self-protection mode in order to avoid "the usual mistakes" when creating scripted object logic in system:inmation. An example is to limit the execution frequency, throttle data calls, set the right auxliary state management and persistence options for child objects etc.
esi-rscripts serve automatically into use case monitoring in an enterprise:inmation environment. They create historizing KPI source objects and the corresponding dashboard elements, so that system administrators have all options to monitor the error-free execution of the scripts, or be very fast with the root cause analysis, in case something should go wrong.
esi-rcode can be easily machine-generated, e.g. from configurational metadata in Excel, database tables or other means