Introduction
This example takes the very simple flow element described in the simple flow element example, and adds a data file, upgrading the flow element to an aspect engine.
Instead of storing data statically, as the simple flow element example did, this example will store it in a data file which will be loaded and can also be updated.
Download Example
The source code used in this example is available here:
Dependencies
The aspect engine will need a dependency on the Pipeline engines package now as it is implementing an aspect engine rather than a flow element.
FiftyOne.Pipeline.Engines
NuGet package. pipeline.engines
Maven package from com.51degrees
. To include this, add the following to the <dependencies>
section of the project's pom.xml
:
fiftyone.pipeline.engines
NPM package to the package.json, and required it in the source with require("fiftyone.pipeline.engines")
. Data
The element data implemented in the previous example can now be upgraded to implement an aspect data.
IElementData
, the IStarSignData
will now implement IAspectData
which extends IElementData
.
Now the internal implementation of it will implement a 'getter' and add a 'setter' for StarSign
in the same way as the previous example.
ElementData
, the StarSignData
will now implement AspectData
which extends ElementData
.
Now the internal implementation of it will implement a 'getter' and add a 'setter' for StarSign
in the same way as the previous example.
Note that this concrete implementation of StarSignData
sits in the same package as the aspect engine, not the StarSignData
interface, as it only needs to be accessible by the aspect engine.
aspectDataDictionary
can be used. Aspect Engine
Now the actual aspect engine needs to be implemented. For this, the class from the previous example will now implement the on-premise engine's base class.
OnPremiseAspectEngineBase
(which partially implements IOnPremiseAspectEngine
). This has the type arguments of IStarSignData
- the interface extending aspect data which will be added to the flow data, and IAspectPropertyMetaData
- instead of IElementPropertyMetaData
.
The existing constructor needs to change to match the OnPremiseAspectEngineBase
class. So it takes the additional arguments of a data file path, and a temporary data file path. This is the location of the data file that the aspect engine will use, and where to make a temporary copy if required.
The constructor will also read the data file containing the star signs into memory. This is done in another method so that it can also be used by the RefreshData
method when a new data file is downloaded (this is not applicable for this example as star sign data will not change).
The Init
method in this example will simply read a CSV file with the start and end dates of each star sign, which looks like:
and add each to a list of a new class named StarSign
which has the following simple implementation:
Note that the year of the start and end date are both set to 1, as the year should be ignored, but the year 0 cannot be used in a DateTime
.
The new Init
method looks like this:
Now the abstract methods can be implemented to create a functional aspect engine.
OnPremiseAspectEngineBase
(which partially implements OnPremiseAspectEngine
). This has the type arguments of StarSignData
- the interface extending aspect data which will be added to the flow data, and AspectPropertyMetaData
- instead of ElementPropertyMetaData
.
The existing constructor needs to change to match the OnPremiseAspectEngineBase
class. So it takes the additional arguments of a data file path, and a temporary data file path. This is the location of the data file that the aspect engine will use, and where to make a temporary copy if required.
The constructor will also read the data file containing the star signs into memory. This is done in another method so that it can also be used by the refreshData
method when a new data file is downloaded (this is not applicable for this example as star sign data is static).
The init
method in this example will simply read a CSV file with the start and end dates of each star sign, which looks like:
and add each to a list of a new class named StarSign
which has the following simple implementation:
Note that the year of the start and end date are both set to 0, as the year should be ignored.
The new init
method looks like this:
Now the abstract methods can be implemented to create a functional aspect engine.
First let's change the class to extend engine
.
The existing constructor needs to change to match the engine
class. So it takes the additional argument of a data file path. This is the location of the data file that the aspect engine will use.
The constructor will also read the data file containing the star signs into memory. This is done in another method so that it can also be used when a new data file is downloaded (this is not applicable for this example as star sign data is static).
The refresh
method in this example will simply read a JSON file with the start and end dates of each star sign, which looks like:
and parse into objects.
The new refresh
method looks like this:
Now the abstract methods can be implemented to create a functional aspect engine.
Builder
Now the aspect engine needs one final thing, an element builder to construct it. This needs to provide the aspect engine with a logger and an aspect data factory as in the previous example. However, it also now needs a data file.
SingleFileAspectEngineBuilderBase
.
SingleFileAspectEngineBuilderBase
.
Usage
to give an output of:
to give an output of:
To print the star sign of the user.
Next Steps
The Custom Client-Side Evidence example shows how you can build a custom engine that can take evidence supplied by the client.