Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The trigger schema adds event generation and catching capabilities for an existing EXPRESS Schema

Current state of the EDM Extension schema

  • Specification version 0.1 made, see below
  • new reserved words:
    • TRIGGER_SCHEMA
    • TRIGGER_FUNCTION
  • avoid introducing reserved words EVENT and TRIGGER as they will most likely collide with attribute names some time.

 

Code Block
SCHEMA MyExpressSchema;
	ENTITY MyEntity;
		attr1 : STRING;
	END_ENTITY;
END_SCHEMA;

TRIGGER_SCHEMA MyTriggerSchema FOR MyExpressSchema;
	DECLARE target_model INSTANCE OF MyExpressSchema;

---------------------------------------------------------------------------
-- the system recognized events is proposed to define as INTEGER XPX pseudo constants
-- then we can expand range of trigger events without enhancing grammar 
-- declaration can be assumed as something like:
---------------------------------------------------------------------------
trigger_source = ENUMERATION OF(
		XPX_Create_Entity,		-- raised after entity is created
		XPX_Delete_Entity,		-- raised before an entity is deleted
		XPX_Read_Entity,		-- any attribute is accessed
		XPX_Write_Entity,		-- any attribute is modified

		XPX_Pre_Set_Attribute,		-- raised before specified attribute is assigned (do we need PRE/POST?)
		XPX_Post_Set_Attribute,		-- raised after specified attribute is assigned (do we need PRE/POST?)
		XPX_Pre_Unset_Attribute,	-- raised before an attribute is set to UNSET
		XPX_Post_Unset_Attribute,	-- raised after an attribute is set to UNSET
		XPX_Read_Attribute,			-- any attribute is accessed

		XPX_Create_Model,		-- raised after model is created
		XPX_Delete_Model,		-- raised before model is deleted
		XPX_Read_Model,			-- raised if any data in model accessed (pre)
		XPX_Write_Model,		-- raised if any data in model written (pre)

		XPX_Commit_Write_Transaction,		-- raised just before write transaction committed (what about tx levels?)
		XPX_Abort_Write_Transaction,		-- raised just before write transaction aborted(what about tx levels?)

	);

---------------------------------------------------------------------------
-- we use the DECLARE keyword to connect events to handlers 
-- Pattern: DECLARE trigger_function TRIGGER_FUNCTION(trigger_source) FOR (target);
---------------------------------------------------------------------------	
	DECLARE EntityTrigger 		TRIGGER_FUNCTION(XPX_Create_Entity) 	FOR MyEntity;
	DECLARE AttributeTrigger 	TRIGGER_FUNCTION(XPX_Pre_SetAttribute) 	FOR MyEntity.MyAttribute;
	DECLARE ModelTrigger 		TRIGGER_FUNCTION(XPX_Create_Model) 		FOR target_model;

	
	TRIGGER_FUNCTION EntityTrigger(theEntity: GENERIC_ENTITY) : GENERIC;
		RETURN(?);
	END_TRIGGER_FUNCTION;

	TRIGGER_FUNCTION AttributeTrigger(theEntity: GENERIC_ENTITY) : GENERIC; -- look in DECLARE TRIGGER declarartion to identify attribute
		RETURN(?);
	END_TRIGGER_FUNCTION;

	TRIGGER_FUNCTION ModelTrigger(theModel: GENERIC_ENTITY) : GENERIC; -- theModel will refer to SDAI_MODEL instance
		RETURN(?);
	END_TRIGGER_FUNCTION;
	
	
---------------------------------------------------------------------------
-- so for possibility to user defined events
-- firstly the events need to be enumerated somehow. Not trivial as they are cross-schema and cross-model
-- could be kept in a trigger schema, meaning both raise and catch must be done within that schema.
-- anyway, if identified as integer constants we may declare them as such:
---------------------------------------------------------------------------	
	CONSTANT
		somethingCreatedEvent : INTEGER := 1001;
		somethingDeletedEvent : INTEGER := 1002;
	END_CONSTANT;
	
-- to raise events - easy way out is to use same technique as for XPX exception:		
	PROCEDURE ThrowAnEvent(arg : GENERIC);
		xpxRaiseEvent(eventType,eventTarget,.....);
	EBD_PROCEDURE;
	

-- to catch events is like catching trigger events, so we use same declaration
-- Pattern: DECLARE eventHandler TRIGGER(eventType) FOR target; -- target is a model I think...
	
	DECLARE EventHandler TRIGGER_FUNCTION(somethingCreatedEvent) FOR target_model;
	DECLARE EventHandler TRIGGER_FUNCTION(somethingDeletedEvent) FOR target_model;
	
	TRIGGER_FUNCTION EventHandler(event : GENERIC_ENTITY) : GENERIC;
	LOCAL
		myEventType : INTEGER;
	END_LOCAL;
		myEventType := event.eventType;
		RETURN(?);	
	END_TRIGGER_FUNCTION;
	
END_TRIGGER_SCHEMA;

 

  • Code block kept for convenience.
Code Block
ENTITY xIfcWorkTask SUBTYPE OF(IfcTask);    
    subTaskOf : xIfcWorkTask;
    dependentOn : SET[0:*] OF xIfcWorkTask;
END_ENTITY;

 

  • The attributes declared in an EXTENSION_SCHEMA  can in addition to the "normal" domains also be of type GENERIC_ENTITY and EDM specific types like _FILE and _DATETIME;
  • The acronym is "EEX" from EDM EXPRESS Extension Schema, and is also the file extension used for such files.Apart from specific extensions grammar in TRIGGER_SCHEMA is close to QUERY_SCHEMA apart from QUERY_FUNCTION 
    • Or, we might just add TRIGGER capabilities to QUERY_SCHEMA?
  • The acronym is "TEX" from Trigger EXtension, and is also the file extension used for such files.

Current state of the EDM Trigger Schema

Subscribing to events from a client

The intention is that client applications can retrieve events from the EDM server. Proposal for a general approach:

  • Events, here-under "trigger events" are generated 
    • from XPX code using xpxRaiseEvent(...)
    • or from EDMI code (plugins,...) using edmiRaiseEvent(..). Note that no remote version of function is available, as events are always generated on server (TODO: is this correct?)
  • A client can subscribe to events. Events can be pushed (sent) or pulled (polling a queue). In either case a subscription must be active.
  • To initiate subscription use function edmiRemoteSubscribeToEvents(...)
  • To read events from queue use edmiRemoteGetEvents(...)
  • To enable event push use edmiRemoteSetEventHandler(...)
  • Or variations of the above

Event handlers from client can for example be:

  • A web "server" receiving HTTP(s) requests - typically REST calls 
  • An application like MSM providing a callback RPC function (hmm...)

Q&A:

What is aim to introduce the stuff?

...

Note

Comments wanted!

Since we are about to enable EEX TEX in the EDM it is importrant that any missing or non optimal functionality are noted and corrected. Comments can be posted here or sent to Arne T.

...