The page describes the extension point details for the Order microservice.

Delegates

Delegates are a useful construct in event-based systems. Essentially, Delegates are objects that encode a method dispatch on a specified object.

In the Order microservice, Delegates are used to process data and perform certain actions of the task nodes in the order flow. For example, PreProcessPaymentDelegate triggers message event to payment service with the payload. PreProcessPaymentResponseDelegate receives the response from payment service and performs the transaction.

The Order microservice has an abstract adapter that would be extended by other process Delegates. The abstract adapter exposes process method for the delegate process. The method name is process with parameters DelegateExecution and Order. A user-defined process like event trigger, state transition, and message queue can be implemented inside the process method (e.g. java process(DelegateExecution execution, Order order)).

Reports Order Plugin

The Reports order plugin is used to generate distinct types of reports related to order collection in the database based on a lot of dynamic factors.
This plugin can be deployed when the admin console requires the reporting features and removed when the admin console does not need them. The order data for the reports is fetched from MongoDB Order Collection using an aggregation query based on the parameters that are selected while generating the report.

How to Integrate Generic Plugin with Order microservice

Selecting a Plugin

To make the order to flow through a required plugin, the collection property omsIntegration holds the plugin name. Using the value given in that property, API implementation classes will be selected.

The order service will load all the beans with the service interface names from the context. This includes all the implementation classes of those interfaces as those classes will be implementing those interfaces.

The following rules are followed:

The name of the implementation class must be similar to InterfaceName followed by Impl.
If you will create a Plugin, then the implementation class should be prefixed with the plugin name. So, the service implementation classes should be defined in the following way:

<plugin name>+<service name>+Impl

For example,

“pluginOne-oms-plugin” is a plugin which is an extension of orders. The service APIs which are implemented in this plugin should be prefixed with plugin name. Let’s say, create order service is the API, which is extended in this plugin, then the class name can be “PluginOneCreateOrderServiceImpl”. And the value that need to be provided in the collection property “omsIntegration” is “pluginOne”.
“Epoch-oms” is a plugin which is created for get order service. The implemented service APIs are prefixed with ‘epoch’. So, the getOrderService is defined as “EpochGetOrderServiceImpl“. The value that needs to be provided in the collection property “omsIntegration” is “epoch”.
“newgistics-shippinglabel-plugin” is a plugin created for return shipping label generation. This plugin is invoked when a Return and Exchange order is created, which in-turn connects with plugin and generates shipping label, and the links are stored in the Order entity. A separate API is exposed to fetch the label alone.

Creating Extended Services

The order service has defined set of APIs to perform order-related operations. Each API is constructed with the help of its corresponding interfaces. The extension plugins should construct the extended version of APIs by implementing the defined interfaces in the order service.

For example,

GetOrderService is the interface common for both the service and plugin.
GetOrderServiceImpl is the implementation class for the service.
EpochGetOrderServiceImpl is the implementation class for Epoch (Plugin).

Shipping Label Plugin

This plugin is invoked whenever an Exchange and Return order is placed, which performs a collection property lookup to connect to the configured plugin and get the label generated. The following collection properties are defined:

shippingLabelImplClass: This property contains the class name that needs to be invoked for generating shipping labels.
shippingLabelPluginConfiguration: This property contains the configuration required to connect the third-party services that are responsible for creating labels.
fetchShippingLabelFromDB: This property flag determines if the label needs to be retrieved from the database or not for each successive request.

marketplace-oms-plugin

This plugin is used to send the fat events on top of thin events. When order patch is done to change the order status (for example, when the order moves from submitted to shipped), the fat events override the existing thin events. For more information, refer to List of Fat Events and Event Payload With and Without Fat Event sections.

For example, the following method from the abstract class EventProcess is overridden in the extension plugin for the order service:

public void updateEventPayload(InputModel input, OutputModel output, EventPayload<Object> event) {}

The parameters for the marketplace-oms-plugin are: –

input: this parameter is used to send the request object.
output: this parameter is used to send the response object.
event: this parameter is used to send the thin event object to update the FAT events.

For example,

public class OmsEvent extends EventProcess
public void updateEventPayload(InputModel input, OutputModel output, EventPayload<Object> event) {}

The following table describes the extension point details:

Extension Point Name	Description	Extension Interface Method Signature
`com.skava.newgisticsplugin.impl.NewgisticsShippingLabelStrategyImpl`	This plugin is invoked when a return or exchange order is placed. It connects with the third-party service Newgistics. The collection property 'shippingLabelImplClass' holds this extension point name. It generates the shipping label. The generated label is stored in the `Order` entity.	`Map createShippingLabel(Map pluginProperties, Order order); Map getShippingLabel(Map pluginProperties, long collectionId, Order order, String itemId);`
`com.skava.oms.strategy.impl.DefaultGetShippingLabelStrategyImpl`	This plugin is invoked when a return or exchange order is placed. This is the default implementation. The collection property 'shippingLabelImplClass' holds this extension point name. It generates the sample shipping label. The generated label is stored in the `Order` entity.	`Map createShippingLabel(Map pluginProperties, Order order); Map getShippingLabel(Map pluginProperties, long collectionId, Order order, String itemId);`

Extensions – Order