Declarative Scripting Made by ESI
The ESI libraries are now incorporated into the internal Lua libraries of the system and are updated as part of regular product development. The esi git repository is still available but will not updated in future. Requests for improvements can still be made by ESI community members there or by contacting our support team. |
This document explains the principles of Declarative Scripting support, being part of the overall ESI ecosystem. We will
also refer to ESI Rails
or esi-r
which is also the required prefix for any ESI Rails library added to this
repository.
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 esi-r
concepts.
Convention over Configuration (CoC)
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 Lua
or 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.
Don’t Repeat Yourself
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.
The ESI way
In the following section, we list the benefits and the requirements esi-r
brings with itself.
Use Case-centric Scripts
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 TableHolder
in the I/O Model
onto the KPI Model, 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 can be esi-r
, but
must not)
Scripts with no branches and no loops (and very little complexity) \{#Scripts with no branches and no loops }
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.
Benefits
There is a long list of benefits:
-
All
esi-r
scripts 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-r
scripts turn simpleActionItems
orGenericItems
into full-blown use case objects, supplying historized variables for performance tracking, configurational control etc. -
esi-r
scripts are self-explaining to a very high degree -
esi-r
scripts 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 auxiliary state management and persistence options for child objects etc. -
esi-r
scripts 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-r
code can be easily machine-generated, e.g. from configurational metadata in Excel, database tables or other means