Difference between revisions of "Signal DSL"

Revision as of 13:04, 29 October 2018

Purpose

POS master data updates over signal watchers, to execute a list of tasks (for now only import and/or export via datainterchange) depending on newly created files. This so called trigger-file will be deleted after the execution of all the tasks (or actions) weither they are be executed sequentially or parallel.

A client wishes to export a certain amount of data (sales, reports, master data...) on a specific working day (or not) at a certain time, either once or several time on this date. Therefore, it should now be possible to define such characteristic inside a model.

SignalDSL

The SingalDSL defines the java functions for Os.bee and the functions will be used in other Os.bee models. The main semantic elements of the SingalDSL are:

• package - The root element that contains all the other elements. (now in one file only one package could be defined, the grammar could be altered to support several packages in one file, if needed)
• import declarations - Used to import external models or other Java classes.
• watcher - define a watcher which monitors a directory.
• filemask - define a group of target files to watch and all detail about the watcher.
• filename - define a target file to watch and detail about the watcher.
• scheduler - define the simple or complex schedulers for executing tens, hundreds, or even tens-of-thousands of jobs.

package defintion

With the keyword package followed by a qualified name, you define the root element that contains all the other elements. A model can contain multiple packages.

► Syntax:

package <package name>[{ 
	(
	  watcher <watcher name>
		  filemask <file mask> . . .
		| filename <file name> . . .

	| scheduler <scheduler name> . . .
	)* 
}]

• one or more watcher/scheduler can be defined in the same package.
• 2 types of watcher can be defined, they are file mask watcher and file name watcher.
• The trigger policy defines how the execution of its list of tasks be triggered: either file based (the creation of a file) or scheduled plan based.
  • Currently we only support the export and import functions of existing datainterchange units from the datainterchangeDSL as the possible watcher’s/scheduler’s tasks to be executed.
  • The properties of datainterchangeDSL are saved in the datainterchange configuration files which are generated with the datainterchangeDSL.
  • The datainterchange configuration files are default saved in C:\Users\<user name>\.osbee. Per datainterchange group, a <groupname>Config.xml file will be generated automatically. This file path can be changed in Eclipse--> Preferences--> OSBP Application Configuration -->External Data Source --> Datainterchange Setting.
  • The corresponding watcher's and scheduler's properties defined in SingalDSL will be added into the corresponding datainterchange-group-configuration files after saving the SignalDSL file.
  • In cases the needed datainterchange properties are not available in the configuration file, or the configuration file doesn't exist, the default definition of the properties from the datainterchangeDSL file will be used.
  • Currently it is not possible to monitor changes on a (web)url-based directory (destination). You may however define a watcher with a url-based directory and set schedulers to import data from it.

Watcher

Watcher jobs are generated by a watcher, they will be stored into a queue and processed by the watcher job handler.

► Syntax:

watcher <watcher name>
	filemask <file mask>
		sequential | parallel
		from <DataInterchange Group>
	{
		import|export <DataInterchange Unit> [applyon]
	}

	| 
	filename <file name>
		sequential | parallel
		from <DataInterchangeGroup>
	{
		(import|export <DataInterchange Unit> [applyon])*
	}

• 2 types of watcher can be defined, they are:
  • file mask watcher:

    We provide the possibility to set a file mask to extend the further specify (and identify) on a file name basis, the defined task will be executed when the matched files creations occur in the monitored directory.

  • file name watcher:

    A specified file name can be defined as the target file, and a list of tasks will be executed when the matched file creation occurs in the monitored directory.

Scheduler

The scheduler functionalities are built upon the Quartz Job Scheduler Framework.

Scheduler jobs are timely executed at run-time based upon their scheduler definition.

► Syntax:

scheduler <scheduler name>
	 <scheduler expression>
	[sequential|parallel]
	from <DataInterchange Group>
{
	(import|export <DataInterchange Unit> [applyon])*
}

scheduler expression

You are able to define an hourly, a daily, a weekly or a monthly schedule plan, to set when to execute the list of tasks of a Scheduler. Additionally, you can also be more straightforward and define a more complex schedule plan with cron-expressions.

More information about how to build cron-expressions can be find here.

hourly scheduler

hourlyat <minute INT>

daily scheduler

dailyat <hour INT> : <minute INT>

weekly scheduler

weeklyon <Day Of Week Enum> at <hour INT> : <minute INT>

• Day Of Week Enum is including sunday, monday, tuesday, wednesday, thursday, friday and saturday.

monthly scheduler

monthlyon <day of month INT> at <hour INT> : <minute INT>

cron scheduler

cron <expression STRING>

Copyright Notice

All rights are reserved by Compex Systemhaus GmbH. In particular, duplications, translations, microfilming, saving and processing in electronic systems are protected by copyright. Use of this manual is only authorized with the permission of Compex Systemhaus GmbH. Infringements of the law shall be punished in accordance with civil and penal laws. We have taken utmost care in putting together texts and images. Nevertheless, the possibility of errors cannot be completely ruled out. The Figures and information in this manual are only given as approximations unless expressly indicated as binding. Amendments to the manual due to amendments to the standard software remain reserved. Please note that the latest amendments to the manual can be accessed through our helpdesk at any time. The contractually agreed regulations of the licensing and maintenance of the standard software shall apply with regard to liability for any errors in the documentation. Guarantees, particularly guarantees of quality or durability can only be assumed for the manual insofar as its quality or durability are expressly stipulated as guaranteed. If you would like to make a suggestion, the Compex Team would be very pleased to hear from you.

(c) 2016-2024 Compex Systemhaus GmbH