Introduction
This example takes the very simple flow element described in the simple flow element example, and delegates all the logic to a cloud service.
Instead of the data being stored locally and processing being carried out by the flow element directly, as demonstrated in the simple flow element example, this example will call a cloud service to perform the required functionality.
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, and cloud request engine package
FiftyOne.Pipeline.Engines
and FiftyOne.Pipeline.CloudRequestEngine
NuGet packages. pipeline.core
Maven package from com.51degrees
. To include this, add the following to the <dependencies>
section of the project's pom.xml
:
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.
Aspect Engine
Now the actual aspect engine needs to be implemented. For this, the class from the previous example will now implement the cloud aspect engine's base class.
CloudAspectEngineBase
. 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 CloudAspectEngineBase
class.
The constructor will also take a CloudRequestEngine
instance to get the available properties from.
Now the abstract methods can be implemented to create a functional aspect engine.
CloudAspectEngineBase
. 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 CloudAspectEngineBase
class.
The constructor will also take a CloudRequestEngine
instance to get the available properties from.
The loadAspectProperties
method in this example will get the aspect properties from the CloudRequestEngine
and store them. In this case we know the only property will be 'star sign', but more complex cloud engines can have many properties.
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 cloud request aspect engine.
CloudAspectEngineBuilderBase
.
CloudAspectEngineBuilderBase
.
Usage
CloudRequestEngine
, and used like:
to give an output of:
CloudRequestEngine
, and used like:
to give an output of:
Next Steps
The Custom On-premise Engine example shows you how to build an on premise engine to perform the functionality that was executed by the cloud engine here.