Everything starts up small – and some things never stops to grow. Pretty soon you have a big system on your hands that needs to send data here and there thru the enterprise. You then start to whish that you had some very exact way to identify a specific object – like a globally unique identifier – a GUID.
When importing reference data into a system, it is very important that the producing system keep tracks of the objects that has been deleted. Otherwise the importing system will have no way to know that some of the reference data it has actually should not exist any more.
Having these kinds of import and exports between systems is key to the idea of service oriented architecture SOA. When you have good access to reference data you will have no problem in letting the system you create focus on one task only – leaving maintenance of the reference data to someone else.
It is however important that the coupling between multiple systems is done loosely – so that your collected environment does not become as brittle as it will if all things require that everything else works in order to produce a result. The correct strategy is to use asynchronous connections between systems.One good way to get asynchronous discovery of new or changed data is to have timestamps on objects.
So where is all this going? Well it is just hygiene – something that needs to be in place if you want to get a complex environment working.
This is how you can get the necessary hygiene into a system built with ECO or BoringPredictable:
Set the SuperClass as the Default super class for the package:
In the method body for OnCreate set this ocl:
In the method body for OnUpdate set this ocl:
In the method body of OnDelete set this ocl:
let x=DeletedObj.Create in
And voila – when you create an object of any class in your package you get a CreateTime and a GUID:
And when you have saved the new object it gets a ChangeTime.
And when you delete an object we get a new DeletedObject created with the DeletedGuid kept:
Note: The OnCreate,OnUpdate,OnDelete are new methods that we will trigger if found on any class for its respective event (Create,Update,Delete). Also the NewGuid operation is new from 2012-03-15.
Update: Yet another event method has been added: OnStateChange(attrib:String; oldstate:String; newstate:String) . Any class with this method signature will get called for each trigger-call that is made on the statemachine. The main intended use is audit and logging functionality. When you use state machines heavily to track important events in your business – this becomes important. The event method is NOT for stopping transitions – use guards for that. You can solve logging by implementing state effects or entry actions as well – but the OnStateChange method helps you to pull out generic logging from the state machines.