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.

Select a tab to view language specific dependencies.

The only dependency needed for .NET is the FiftyOne.Pipeline.Engines NuGet package.

The only dependency needed for Java is the pipeline.engines Maven package from com.51degrees. To include this, add the following to the <dependencies> section of the project's pom.xml:

<groupId>com.51degrees</groupId>

<artifactId>pipeline.engines</artifactId>

</dependency>

Add a dependency to the 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.

Select a tab to view language specific aspect data implementation.

Instead of implementing 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.

Instead of implementing 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.

Node's implementation of element data does not require concrete getters for IDE autocompletion, so 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.

Select a tab to view language specific aspect engine implementation.

First let's change the class to extend 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:

Aries,21/03,19/04

Taurus,20/04,20/05

Gemini,21/05,20/06

Cancer,21/06,22/07

...

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.

First let's change the class to extend 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:

Aries,21/03,19/04

Taurus,20/04,20/05

Gemini,21/05,20/06

Cancer,21/06,22/07

...

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.

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.

Select a tab to view language specific element builder implementation.

As this aspect engine is using a data file, the builder can make use of the logic in the SingleFileAspectEngineBuilderBase.

Usage

Select a tab to view language specific usage.

Next steps

The Custom Client-Side Evidence example shows how you can build a custom engine that can take evidence supplied by the client.

51Degrees API Documentation 4.4

Custom On-Premise Engine