Wizzi jobs are the task manager of the Wizzi factory. They execute a sequence of Wizzi model loadings and artifact generations .
They are configured using `wfjob` ITTF documents, and are execute using the `executeWizziJob` method of a wizzi.WizziFactory instance or the `wizzi` command of the ` wizzi-cli ` CLI package.
The `wfjob` Wizzi schema, implemented by the `wizzi-core` plugin, is the configuration schema of a Wizzi job.
1 wfjob wizzi-docs-concepts 2 models-base-folder ${models_folder} 3 model concepts 4 src wizzi-jobs.docs.ittf 5 schema docs 6 line html 7 cwd-folder ${html_folder} 8 model-ref concepts 9 transformer docs/preprint 10 production 11 dest-folder ${dest_folder} 12 line-ref html
1 wfjob {wzName} 2 string title `short-description` 3 # For info and error messages 4 string models-base-folder `path` 5 # The base path to use when the 'src' attribute of models is a relative path 6 string dest-base-folder `path` 7 # The base path of the destination folder of artifacts generated by this job 8 # Can be overridden by the 'dest-folder' attribute of Line elements 9 [ models 10 [ lines 11 [ productions
A model can be:
1 ... 2 model `model-name` 3 string src `path` 4 # The source path of the ittf document or POJO module. 5 # When relative the base path is the 'models-base-folder' attribute of the 6 # WfJob element. 7 string schema `schema-name` 8 # The name of the Wizzi Model type (wfschema) that will load the 9 # mTree defined in the source ittf document. 10 # Is alternative to the 'format' attribute. 11 string format `format-name` 12 One-of 'json', 'nodejs' 13 # Is alternative to 'schema' attribute. 14 string dump-file `path` 15 [ modelRefs 16 # References to the models to be used, as properties of the mTreeBuildUpContext 17 # parameter, passed to the wizzi-mtree.loader.loadMTree function, 18 # for loading the model mTree.
1 ... 2 model-ref `model-name` 3 string export-name `name` 4 [ transformers
Production lines declare artifacts that are processed asynchronously and concurrently.
1 ... 2 line `line-name` 3 string cwd-folder `path` 4 string dest-folder `path` 5 [ artifacts
An Artifact element declares one artifact production that is driven by a source model. Each production has one driver model, but an Artifact element can result in many production because the 'src' attribute of this element may refer to:
1 ... 2 artifact `artifact-name` 3 # For info and errors messages. 4 string src `path` | `glob-pattern` 5 # Can be: 6 # . the path of a final artifact that must be simply copied in the destination path. 7 # . the glob-pattern of final artifacts that must be simply copied in the destination path. 8 # . the path of a source ittf document 9 # . the glob-pattern of sources ittf documents 10 schema `schema-name` 11 # When the 'src' attribute is the path of an ittf document, is the wizzi 12 # model type (wfschema) that will load and validate the document. 13 # Is alternative to the 'format' attribute. 14 # Can be null if the artifact is a final artifact. 15 ignore `path` | `glob-pattern` 16 # Files returned by the 'src' attribute glob-pattern that are to be ignored. 17 # Can be a glob pattern. 18 generation `artifact-generator-name` 19 # The name of the artifact generator that will produce the artifact. 20 # When the artifact is a final artifact must be omitted. 21 dest-path `artifact-file-path` 22 # The 'src' attribute is the default 23 # relative destination path of the generated artifact, 24 # but, when set, this attribute overrides the default. 25 # It may be an absolute path. 26 extension `artifact-file-extension` 27 # The path extension of the generated artifact. 28 # Optional. The default is the 'src' atribute path extension without 29 # the ending '.ittf' string. 30 # Child elements 31 [ modelRefs
Production elements contain a list of references to previously declared production lines that must be sequentially executed.
1 ... 2 production 'production-name' 3 string dest-folder `path` 4 [ lineRefs
1 ... 2 line-ref `line-name`
When the Wizzi factory is used in a server application, or in a long running process where many jobs are executed, it is useful to access factory services, prepared at startup, directly from the JsWizzi code inside ITTF documents.
There are two jswizzi global functions for this purpose.
Allow to call a user function declared on start up.
Allow the retrieval of a Wizzi Model preloaded on start up.
... TODO ...
This event is raised before creating the runnerServer instance. At this point we can call the config.get(propertyName) and config.set(propertyName, value) methods on the config object.
This event is raised before the initialization of the wizzi factory contained in the runner server. At this point we can call the runnerServerInstance.registerApi(name, function) method, the runnerServerInstance.registerPlugin(pluginNameOrPath) method and the runnerServerInstance.registerGlobalContext(object) method.
This event is raised when the wizzi factory contained in the runner server has benn initialized. Now it is forbidden to call the registerPlugin and registerGlobalContext methods but we can call the runnerServerInstance.loadModel and runnerServerInstance.transformModel methods.