Splicer Architecture
- Petr Buncik
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.
You should read Splicer to fully understand terminology used in the following paragraphs.
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.
Below paragraphs summarize architectural components of Splicer that correspond to used Python packages.
Main Application (package TM1Splice)
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. Its logic is stored in splicer.py. Second is supporting class that implements all the functionality of Splicer exposed to the CLI and decomposed to specific methods. The implementation is stored in TM1SpliceExecutor.py and represented by class TM1SpliceExecutor. This class is a the most important part of Splicer - the logic of splicing and desplicing is implemented by the class with help of other below described packages.
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
Package 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: Parsing expression grammar
Package Parser/Grammar
The TM1 rule 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 regions and directives with splicing instructions. The other tokens are ignored by the parser and are passed through.
Package Objects
The architecture of Splicer uses classes in Object package to represent various TM1 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.
Package Containers
Similarly as in object case these classes represent syntactical constructs, but in this case owned by Splicer. The classes are containers of objects that are subpackage of Containers with exception of TM1SpliceConfigContainer. These are described in below table.
Class | Usage |
|---|---|
| Container of all splicing directives represented by objects of |
| Used to retrieve directives that apply to instance of |
| Used to store regions of the TM1 rule, the container stores start and end positions (measured in characters from start of the rule) of each region. Each region might be defined several times in the rule, this feature is supported by |
| Represents all instances of named region enclosed in pair of |
| Container of desplicing (directives reversing splicing) directives represented by |
| Used to retrieve reverse directives that apply to instance of |
| Configuration container responsible for loading configuration from config files |
Package Containers/Objects
The contained classes represent contained objects by containers described in above paragraph. The classes are described in below table.
Class | Usage |
|---|---|
| Represents a single splicing directive defining its identifier, splicing region, its dimensional scope and associated regular expression to identify elements for splicing. |
| Represents a single instances of named region enclosed in pair of |
| Represents a single reverse splicing directive derived from a splicing directive, but implementing original directive reversal. |
Â