Below paragraphs summarize architectural components of Splicer that correspond to used Python packages.
Splicer project source code is hosted in following Bitbucket repository: https://bitbucket.org/apliqoc3ux/rule-splicing-tool/src/RuleID/
The production branch of the project is RuleID.
Main Application
Splicer is designed as an application with command line interface. Interaction with the TM1 server is provided through a wrapper TI process which will prepare a batch file containing code to execute Splicer. The wrapper will handle all process parameter values so the command to call Splicer is properly formulated in correct CLI syntax.
The main application is defined in TM1Splice package and consists of two parts. First part is the actual application which is responsible for providing CLI and interpreting arguments and switches, second is supporting class that implements
There are currently two modes of execution possible - either to run Splicer in a virtual Python environment or run Splicer executable file. Installation of the Python virtual environment gives better results when Splicer is activated since the load time is considerably faster than in case of executable file produced by pyinstaller. Instructions how to prepare the virtual environment are covered in Python Execution Environment
We have a plan to introduce Splicer as a web service - this is important as TM1 v12 will no longer support running executable files through ExecuteCommand. Splicer wrapper already has support for the web service call, but Splicer should be added web service endpoint.
Parser
Splicer is implemented as an application utilizing parser and providing its rule transformations based on the parser output. Parser is a generated class based on simplified TM1 rule grammar.
Parser is generated by a parser compiler Canopy with output set to Python. Information about Canopy can be found here: https://canopy.jcoglan.com , repository is available here: https://github.com/jcoglan/canopy . Canopy uses PEG (Parsing Expression Grammar) grammar specification, its syntax is described on the project site, theoretical information may be found here: https://en.wikipedia.org/wiki/Parsing_expression_grammar
Parser Grammar
The TM1 grammar implemented in scope of Splicer is covering only area statement of a rule or a feeder statement, the right hand side after equal sign is not used by the parser. Additionally the parser recognizes Splicer specific directives with splicing instructions.
Objects
The architecture of Splicer uses classes in Object package to represent various syntactical constructs (non-terminal symbols) that the Parser recognized when parsing a TM1 rule. These are described in below table.
Class | Usage |
|---|---|
| Represents entire TM1 calculation rule or a feeder statement. |
| Represents area statement of a TM1 calculation rule or a feeder. |
| Represents a single TM1 rule command separated from other commands by semicolon. The command might be |
| Represents a checksum token calculated for each command present in the TM1 rule. This feature was intended to provide mechanism to promote updates to TM1 rules automatically, but currently the feature is not used. |
| Represents all other tokens not covered by previous classes. |
The objects are created by Parser and their attributes are set according to parts belonging to each syntactical construct as they were parsed from the TM1 rule.
For example there is TM1RuleAreaStatement class representing entire area statement of a TM1 rule command. The properties of each object based on this class will contain list of dimensions/hierarchies/elements used in the corresponding TM1 rule command.
The creation of objects consistently aligns with the PEG grammar, ensuring that if there's any uncertainty about what each object signifies or encompasses, one can always consult the grammar for clarification.
Containers
Similarly as in object case these classes represent syntactical constructs