Configure Plug-in Upgrades

A pre-requisite for successful custom plug-in upgrade in Operations Hub.

About this task

Plug-in developers can choose to write a specification, or use any transformation mechanism to get an EXE, JAR, or BAT file.

Procedure

Prepare a data transformation for plug-in upgrade using any of these methods:

Transformation File Type Description

Jolt

Transformation File Type	Description
Jolt	Open-source JSON-to-JSON transformation library written in Java. For more information, refer to https://github.com/bazaarvoice/jolt#Documentation For Jolt spec, you can use http://jolt-demo.appspot.com/ as a playground to test your transformation.
JAR	Java output using JSON transformation library such as https://mvnrepository.com/artifact/net.minidev/json-smart/2.4.7. For JAR, the plug-in upgrade infrastructure looks for the class to load. For example, `public class GEBreadcrumb_3_0_0to3_0_1` wherein, `GEBreadcrumb` is the plug-in name `3_0_0` is the breadcrumb plug-in old version. The dot is replaced with an underscore. `3_0_1` is the breadcrumb plug-in new version. The dot is replaced with an underscore. A transform instance is created for the class by invoking its static transform method: `public static String transform(String inputJSON)`
.EXE	Windows?? executable file. Create a transformation project with your choice of library (C++, Node, Python, etc.), which prints the transformed output json to console. For this executable, 'FromVersion' schema input json is passed as command line argument 'ToVersion' response JSON is read from its console output produced by the executable

Open-source JSON-to-JSON transformation library written in Java.

For more information, refer to https://github.com/bazaarvoice/jolt#Documentation

For Jolt spec, you can use http://jolt-demo.appspot.com/ as a playground to test your transformation.

JAR

Java output using JSON transformation library such as https://mvnrepository.com/artifact/net.minidev/json-smart/2.4.7.

For JAR, the plug-in upgrade infrastructure looks for the class to load. For example, public class GEBreadcrumb_3_0_0to3_0_1 wherein,

GEBreadcrumb is the plug-in name
3_0_0 is the breadcrumb plug-in old version. The dot is replaced with an underscore.
3_0_1 is the breadcrumb plug-in new version. The dot is replaced with an underscore.

A transform instance is created for the class by invoking its static transform method: public static String transform(String inputJSON)

.EXE

Windows?? executable file. Create a transformation project with your choice of library (C++, Node, Python, etc.), which prints the transformed output json to console.

For this executable,

'FromVersion' schema input json is passed as command line argument
'ToVersion' response JSON is read from its console output produced by the executable

Note: Naming convention for the transformation file is <PluginName>-<FromVersion>-<ToVersion>-spec.json. For example GETrendCard-3.0.1-3.0.2-spec.json|jar|exe|bat.

Log in to the machine where Operations Hub is installed.
Place the plug-in transformation files in this location folder ..\ProgramData\GE\Operations Hub\iqp-config\plugin-transform-spec

Results

When Operations Hub administrator imports applications with old plug-ins, they are successfully upgraded to their latest versions.

The transformation engine looks for an incremental path of intermediatory transformation that can migrate a plug-in from a specific version to a desired version. For instance, GETrendCard-3.0.1-3.0.2-spec.json GETrendCard-3.0.2-3.0.4-spec.json GETrendCard-3.0.4-3.0.5-spec.json are used consecutively to upgrade plug-ins.
If incremental upgrades were not performed between Operations Hub versions, then the plug-in version may not remain subsequent for upgrade. For example, consider:
- Operations Hub 1.7 has 3.0.1 version of GETrendCard
- Operation Hub 2.5 has 3.0.5 version of GETrendcard
The GETrendCard-3.0.1-3.0.5-spec.json file may not be available for upgrading plug-ins. In such cases, plug-in upgrades are not performed in Operations Hub.