Sample use cases for customization of alerts

This topic provides a few use cases of alerts implementation that are supported through customization.

Customize alert display descriptions for out-of-the-box alert types

You can override the out-of-the-box alert descriptions by providing descBundleKey in the configuration.
For information on adding new translation literals, see Defining a bundle entry for an existing component or module.

The following JSON specification is for overriding the Hot pick alert type description from High priority to

Hot
pick

static extensionAlertConfig: IAlertsConfig = {
        alertConfigList: [
            {
                personaName: 'Order_Fulfillment',
                alertTypes: [
                        {
                     tid: 'YCD_HOT_PICK',
                     exceptionType: 'YCD_HOT_PICK',
                     descBundleKey: 'alerts.LABEL_HighPick'
                        }
                ]
            }
        ]
    };

Customize alert display component for out-of-the-box alert types

Alert details viewed in the alerts list is rendered by the component defined in Persona-Alert configuration. This component is rendered dynamically based on the alert type.
You can override the out-of-the-box alert component by providing new component in the component property in configuration.

The following JSON specification shows how you can use a new custom alert component CustomHotPickAlertComponent for Hot pick (YCD_HOT_PICK) alert type:

static extensionAlertConfig: IAlertsConfig = {
        alertConfigList: [
            {
                personaName: 'Order_Fulfillment',
                alertTypes: [
                  {
                     tid: 'YCD_HOT_PICK',
                     exceptionType: 'YCD_HOT_PICK',
                    component: CustomHotPickAlertComponent
                  }
                ]
            }
        ]
    };

Note:

Ensure that you import the corresponding alert component, service, or provider classes into alert-extension.module.ts.
Ensure that you are importing from store-extensions-src and not from the store-app-build folder.

Display alerts owned by user's organization

By default, alerts are displayed based on the currently logged-in user as well as the queues to which the user has subscribed. You can display alerts owned by the user's organization by completing the following steps:

Set includeAlertsOwnedByUsersOrganization as ResponseEnum.Yes in extensionAlertConfig property.
Define new alert type configuration for the alert types that you want to view. For new alert types, you can either:
- Create new alert display component and use the component class name in he alert configuration.
- Use generic alert display component GenericAlertComponent, which is provided out of the box. It displays basic alert details like Order number, Shipment number, Shipment status, and Remove alert action. In this case, use GenericAlertComponent as the component class name to be defined in alert configuration.
Note: It is mandatory to define specific alert types when enabling includeAlertsOwnedByUsersOrganization property. Only the alert types that are defined in extensionAlertConfig are displayed on the Sterling Store Engagement user interface.

The following JSON specification shows how you can view YCD_BACKORDER_NOTICE alerts, which are owned by the user's organization, in the alerts list in Sterling Store Engagement:

static extensionAlertConfig: IAlertsConfig =      {
        alertConfigList: [
       {
            personaName: 'Order_Fulfillment',
            alertTypes: [
                   {
                         tid: 'YCD_BACKORDER_NOTICE',
                         exceptionType: 'YCD_BACKORDER_NOTICE',
                          component: BackOrderNoticeAlertComponent, // Or GenericAlertComponent
                          descBundleKey: 'alerts.LABEL_BackorderNotice'
                    }
               ]
        }
      ],
includeAlertsOwnedByUsersOrganization: ResponseEnum.Yes
}

Populating additional data for alerts

You can create custom mashups to suit your business needs and pass additional data to be displayed on the user interface for each alert. You can invoke the custom mashups and return data that is user interface-specific.

The MashupId value is provided in the additionalDataMashupId property. This property is optional. The additionalDataMashupId property is invoked on each Inbox record that are returned by the getExceptionList API. If this property is not defined, the template defined for getExceptionList API mashup is returned to the UI.

Use the following steps to create custom mashups that can be used for populating additional data for alerts:

Create new mashup based on your business needs. You can either create an XAPI or REST based mashup. For more information about creating new mashups, see Extending mashups.
If you are creating XAPI mashup, use the following steps:
1. Create a new mashup implementation class by extending com.ibm.isf.common.mashups.ISFBaseMashup.
2. Override massageInput(Element inputEl, SCUIMashupMetaData mashupMetaData, SCUIContext uiContext) method. This step is mandatory.
3. Inbox element that contains the exception details is appended as child element to the root element of the mashup input.
  For example, if you want to return order details for exceptionType YCD_BACKORDER_NOTICE, you can create a custom mashup (extn_isf.alerts.getOrderDetaits) for invoking the getOrderDetails API, as shown in the following sample alertType configuration:
```
{
   tid: 'YCD_BACKORDER_NOTICE',
   exceptionType: 'YCD_BACKORDER_NOTICE',
   component: ExtnBackOrderNoticeAlertComponent,
   additionalDataMashupId: 'extn_isf.alerts.getOrderDetaits',
   descBundleKey: 'alerts.LABEL_BackorderNotice'
}
```
  The following sample shows the mashup input that us received in the massageInput method:
```
<Order>
       <Inbox Description="" ExceptionType="" ExceptionTypeDescription="" GeneratedOn=""
       InboxKey="" OrderHeaderKey="" OrderNo="" Priority="" ShipmentNo="" ShipmentKey=""/>
</Order>
```
4. You can use the required attributes such as OrderHeaderKey and ShipmentKey from the Inbox element, stamp them on the mashup input, and return the mashup input in massageInput method.
5. Mashup input must contain only those attributes and elements that are defined in the Input element in the mashup definition. Inbox element, being an additional element, must be removed. Failure to do so will result in Mashup security violations at runtime.
  In the previous example, after performing the given steps, the following mashup input is returned from massageInput method:
```
<Order OrderHeaderKey=""/>
```
6. Optionally, you can override the massageOutput method based on your business needs.
The output returned from this custom mashup implementation class is appended as child element to Inbox element and returned to the UI.
As per the example, the order details are appended to each Inbox element of exceptionType YCD_BACKORDER_NOTICE and returned to the UI:
```
<InboxList TotalNumberOfRecords="2">
<Inbox Description="Backorder notice" ExceptionType="YCD_BACKORDER_NOTICE" ExceptionTypeDescription="Backorder notice"  InboxKey="098769" OrderHeaderKey="1234567" OrderNo="1244567" Priority="1" ShipmentNo="1234" ShipmentKey="1234">
    <Order OrderHeaderKey="1234567" OrderNo="1234567" EnterpriseCode="Matrx-R"/>
</Inbox>
<Inbox Description="Backorder notice" ExceptionType="YCD_BACKORDER_NOTICE" ExceptionTypeDescription="Backorder notice"  InboxKey="09876" OrderHeaderKey="123456" OrderNo="124456" Priority="1" ShipmentNo="123" ShipmentKey="123">
    <Order OrderHeaderKey="123456" OrderNo="123456" EnterpriseCode="Matrx-R"/>
</Inbox>
</InboxList>
```
If you are creating REST mashup, use the following steps:
1. Create a new mashup implementation class by extending com.ibm.isf.common.mashups.ISFRestBaseMashup.
2. Override massageInput(Element inputEl, SCUIMashupMetaData mashupMetaData, SCUIContext uiContext) method. This step is mandatory.
3. Inbox element that contains the exception details is appended as child element to root element of mashup input.
  For example, you want to fetch the pick request details by shipment number for each alert and pass this data to the UI. And, when a store associate clicks Pick order or Continue actions, the backroom pick flow is launched by passing pickRequestId.
  The following sample alertType configuration illustrates this example:
```
{
   tid: 'YCD_NEAR_SLA',
   exceptionType: 'YCD_NEAR_SLA,
   component: NearSLAAlertComponent,
   additionalDataMashupId: 'isf.alerts.getPickRequestByShipmentNo'
}
```
  The following sample shows the mashup input received in massageInput method:
```
<RESTData HTTPMethod="GET"  RestURL="stores/Mtrx_Store_1" RestEndPointConfigProperty="yfs.sim.endpointurl" >
       <Inbox Description="" ExceptionType="" ExceptionTypeDescription="" GeneratedOn=""
       InboxKey="" OrderHeaderKey="" OrderNo="" Priority="" ShipmentNo="" ShipmentKey=""/>
</RESTData>
```
4. You can use the required attributes like OrderHeaderKey, ShipmentKey, and ShipmentNo from the Inbox element and pass them as query parameters in RestURL.
5. You must set the following attributes in the mashup input element.
  - HTTPMethod
  - RestURL
    Failure to set correct values for these attributes results in mashup validation failure at runtime.
6. You must remove the Inbox element from the mashup input before returning from the massageInput method.
7. Mashup input must contain only those attributes and elements defined in Input element in the mashup definition. Inbox element, being an additional element, must be removed. Failure to do so will result in Mashup security violations at runtime.
  For example, to get all pick requests for a given ShipmentNo, you must invoke the Store Inventory Management REST API, GET pick-requests. Here,
  - RestURL - stores/<NodeId>/pick-requests?shipmentNo=<ShipmentNo>
  - HTTPMethod - GET
  - MashupInput returned from massageInput method:
```
<RESTData HTTPMethod="GET"  RestURL="stores/<NodeId>/pick-requests?shipmentNo=<ShipmentNo>" RestEndPointConfigProperty="yfs.sim.endpointurl" >
</RESTData>
```
8. Optionally, you can override the massageOutput method based on your business needs.
9. The output returned from this custom mashup implementation class is appended as child element to Inbox element and returned to the UI.
  By default, we invoke Rest Mashup isf.alerts.getPickRequestByShipmentNo for YCD_HOT_PICK and YCD_NEAR_SLA exceptionType to retrieve pick-requests for each shipment. This REST mashup invokes GET pick-requests API on Store Inventory Management and returns pick request details that are eligible for picking appended to the Inbox element. The following sample displays the data that will be received on the UI:
```
<InboxList TotalNumberOfRecords="2">
<Inbox Description="Near SLA" ExceptionType="YCD_NEAR_SLA" ExceptionTypeDescription="Near SLA"  InboxKey="098769" OrderHeaderKey="1234567" OrderNo="1244567" Priority="1" ShipmentNo="1234" ShipmentKey="1234">
    <PickRequest pickRequestId="1234567" status="NOT_STARTED" />
</Inbox>
<Inbox Description="Hot pick" ExceptionType="YCD_HOT_PICK" ExceptionTypeDescription="Hot pick"  InboxKey="09876" OrderHeaderKey="123456" OrderNo="124456" Priority="1" ShipmentNo="123" ShipmentKey="123">
    <PickRequest pickRequestId="123456" status="IN_PROGRESS" />
</Inbox>
</InboxList>
```
To know more about writing mashups for Rest APIs, see Extending mashups .

Note: You must remove the Inbox element from mashup input before returning from massageInput method to avoid mashup security violation during runtime. This applies to both XAPI and REST mashups.