You can extend the Retail Promotion Execution Cockpit app according to your business needs for different aspects. For this purpose, the following extensibility options are available:
Using another OData service: You can use another OData service that holds all necessary data according to your business needs. In general, this is a precondition for all other enhancements you plan in the promotion execution cockpit.
Adding new screen elements on the different screens: You can add more filter criteria to the facet filter bar, new columns in the tables of the different screens, and you can add fields to the header area of the detail screens.
Replacing entire screen elements: You can replace the whole table of the overview screen with your own table columns.
Adjusting header and footer: You can adapt the header and footer area according to your business needs by adding new UI elements, as well as replacing or hiding existing ones from the standard delivery.
Replacing entire views: You can implement your own overview or master detail views, which replace the corresponding standard views. In general, this might also require a replacement of the corresponding view controller.
Adding a new process step: You can add new process steps. The new process step needs a 3-digit identifier, especially for filtering purposes, and a custom detail view for displaying the issue details.
For all the extensibility cases listed above, you might need an enhanced virtual data model (VDM) in the underlying data provisioning layer. The VDM is exposed via an OData service and therefore you might need to replace the call of the standard OData service with your own one.
It will probably be necessary to adjust the data used in your extended promotion execution cockpit. Depending on the kind of enhancement, the following options are available:
Add new fields for the data
Change the calculation of attributes
Add a new process step
Before you start to implement a new OData service for data provisioning, you first have to analyze the meta model of the standard OData service. The more you deviate from this meta model, for example by using different property names or entity type names, the more you need to adapt your extended application. Therefore, if you plan to do only simple enhancements by adding fields on a certain screen, make sure that you use the same property names for the standard delivery fields in your VDM as the standard VDM
The business data of the standard application is taken from different database queries in the backend. These queries are represented as different entity types in the meta model of just one OData service. You can find the standard OData service using the following URL pattern:
http(s)://<server>:<proxy/sap/hba/apps/rtl/s/odata/pec.xsodata
Due to the fact that one query execution requires several mandatory input parameters such as the SAP client or the evaluation time frame in days, two entity types per back end call are involved if you request data from the backend. The first entity type specifies all input parameters in brackets after the corresponding entity set name. Then it uses the navigational property Results to involve the second entity type, which holds the data to be displayed in the application views. . You can access the data of the overview screen using the following URL pattern:
http(s)://<server>:<proxy/sap/hba/apps/rtl/s/odata/pec.xsodata/RetailPromnPrepIssuesQuery(P_EvaluationTimeFrameInDays=9999,P_SAPClient='002',…)/Results
The following table lists all entity type tuples used mainly within the different views:
View | Entity Type/Entity Set for Input Parameters | Entity Type/Entity Set for Business Data |
S1 |
|
|
S2ProcessSteps |
|
|
S3Listing |
|
|
S3PurPriceAct |
|
|
S3SpaPriceAct |
|
|
S3DcaPriceAct |
|
|
S3Allocation |
|
|
S3Sos |
|
|
S3Blocked |
|
|
S3AllocPo |
|
|
S3AllocStk Transpt |
|
|
S3GdsRcpt Vendor |
|
|
S3GdsRcptDC |
|
|
S4GdsRcpt FromVendor |
|
|
S4GdsRcpt FromDC |
|
|
A general description of how to extend a Virtual Data Model and the corresponding OData service(s) provided by SAP can be found in the documentation for here: Retail Promotion Execution Issues.
For a general description of the SAP HANA query views of SAP Smart Business for Retail Promotion Execution and their usage in the UI, see SAP Smart Business for Retail Promotion Execution: Query Views and Their Usage on the UI.
As part of the standard delivery of the Promotion Execution Cockpit, two models are defined in the Configuration.js
file to provide the business data to the different views. Both models request their data from the same backend OData service (see above). The default model PEC
is used within the overview screen (S1) and the second model promoprocsteps
is used within the master detail screens (S2 and S3 views). In order to use your new OData service in your extended application, you need to define, which components of this service list you want to replace with your new OData service identified by the name property.
As a result, the Component.js
file in your extension project contains the following replacement code:
Syntax
config: {
"sap.ca.serviceConfigs": [{
name: "PEC",
masterCollection : "RetailPromnPrepIssuesExtensionQueryResults",
serviceUrl: URI("/tmp/…/odata/pecextended.xsodata/").directory(),
isDefault: true(false),
mockedDataSource : "/<extensionProject>/model/metadata.xml"
}]
},
The replacement information has to be provided for each service name, if the data source is intended to be replaced as well. This is the minimum adaption to implement an OData service replacement.
Besides this replacement definition, further changes are necessary in data provider implementations in order to retrieve business data from the backend. For each view level (S1, S2, and S3) separate data provider implementations are available. The data provider holds metadata that needs to be changed during the application load according to your own meta model. Therefore, each data provider holds information about the entity types and their corresponding entity sets. If these metadata is changed in your new OData service, these configurations have to be changed during the application initialization in the hook method extHookAfterOnInit
defined in the MainCustom.controller.js
object. The same is true for the selection field list, which can be overwritten by using the setSelectFields
method.
Syntax
// change model parameter for S1DataProvider
retail.promn.promotioncockpit.model.S1DataProvider.ENTITY_SET_RESULT = "RetailPromnPrepIssuesExtensionQueryResults";
retail.promn.promotioncockpit.model.S1DataProvider.ENTITY_TYPE_RESULT = "RetailPromnPrepIssuesExtensionQueryResultsType";
retail.promn.promotioncockpit.model.S1DataProvider.ENTITY_SET = "RetailPromnPrepIssuesExtensionQuery";
retail.promn.promotioncockpit.model.S1DataProvider.ENTITY_TYPE = "RetailPromnPrepIssuesExtensionQueryType";
// add Properties to S1DataProvider
retail.promn.promotioncockpit.model.S1DataProvider.setSelectFields("tableQuery", retail.promn.promotioncockpit.model.S1DataProvider. getSelectFields("tableQuery") + ",ExtensionOrg");
The views in the app are orientated in this scheme:
S1 prefixed view/extension points belong to the overview screen
S2 prefixed view/extension points belong to the master list screen
S3 prefixed views/extension points belong to all detail screens, where the fragment S3Detail_ObjectHeader.fragment.xml
is used for the detail header area in each detail screen
To add new screen elements on the different screens (for example more filter lists in the filter bar, columns in the different tables, or new fields on the header area of the detail screens), the following extensibility entities are available:
View | Extension Point | Use |
|
| Add new filter list |
|
| Add new columns to the overview screen table |
|
| Fill new columns on the overview screen table with content |
|
| Replace object header attributes in master list |
|
| Replace first status in object header in master list |
|
| Replace second status in object header in master list |
|
| Add new columns to table on |
|
| Add content to new columns on |
|
| Add new columns to table on |
|
| Add content to new columns to table on |
|
| Add new columns to table on |
|
| Add content to new columns on |
|
| Add new columns to table on |
|
| Add content to new columns on |
|
| Add new columns to table on |
|
| Add content to new columns on |
|
| Add new columns to table on |
|
| Add content to new columns on |
|
| Add new columns to table on |
|
| Add content to new columns on |
|
| Add new labels to the |
|
| Replace first status in object header on detail screen |
|
| Replace second status in object header on detail screen |
|
| Add new labels to the |
|
| Add new columns to table on |
|
| Add content to new columns on |
|
| Add new columns to table on |
|
| Add content to table on |
|
| Change object header attributes on S4 |
|
| Add new columns to table on S4 |
|
| Add content to table on S4 |
You want to use additional filter criteria to restrict the number of promotions with issues on the overview screen. Your new filter criteria are not yet part of standard delivery, so you need to create a new OData service as described in the “Using Another OData Service” section. Afterwards, changes have to be made to the following objects:
Create an implementation of the extension hook method extHookAfterOnInit
from Main.controller.js
in your extension project within MainCustom.controller.js
Implement the extension point S1_FilterBarListExtension
from the overview screen S1.view.xml
to add new facet filter lists. An empty fragment is created, in which you can insert the new filter list.
Syntax
<core:FragmentDefinition xmlns:core="sap.ui.core" xmlns:l="sap.ui.layout" xmlns="sap.m"
xmlns:filterBar="sap.ui.comp.filterbar"
xmlns:app="http://schemas.sap.com/sapui5/extension/sap.ui.core.CustomData/1"
xmlns:mvc="sap.ui.core.mvc" xmlns:vm="sap.ui.comp.variants">
<filterBar:FilterItem name="pecExtensionOrg" id="pecExtensionOrg"
label="{i18n>ZPEC_ExtensionOrg}">
<filterBar:control>
<MultiInput key="pecExtensionOrg" type="Text" name="pecExtensionOrg"
valueHelpRequest="handleListOpen" valueHelpOnly="true">
</MultiInput >
</filterBar:control>
</filterBar:FilterItem>
</core:FragmentDefinition>
Furthermore, the implementation of this extension point is registered in the Component.js
in your extension project:
Syntax
"sap.ui.viewExtensions": {
"retail.promn.promotioncockpit.view.S1": {
"S1_FilterBarListExtension": {
className: "sap.ui.core.Fragment",
fragmentName: "retail.promn.promotioncockpit.<yourExtension>.view.S1_ FilterBarListExtension
Custom",
type: "XML"
},
Within MainCustom.controller.js
extension hook method extHookAfterOnInit
, you need to register the new filter list in the FilterBarEvtHandler
via method addNewFilterList
. As input, this method requires the key of the new filter list as a string, and an object containing the properties for the selection criteria (selectField
), as well as the corresponding description (ODataLabel
) and the corresponding field label (i18nLabel
). Finally, you also need to change the entity set of the new OData service, if its name deviates from the standard delivery
Syntax
// add new field to filter bar
retail.promn.promotioncockpit.utils.FilterBarEvtHandler.addNewFilterList("pecExtensionOrg",
{ selectField : "ExtensionOrg",
oDataLabel : "ExtensionOrg",
i18nLabel : "ZPEC_ExtensionOrg"
});
// change model parameter for FacetFilterDataProvider
retail.promn.promotioncockpit.model.FilterBarDataProvider.ENTITY_SET = "RetailPromnPrepIssuesExtensionQuery";
The i18nLabel is stored in a copy of the standard i18n
resource bundle. These copies are stored in the i18n
folder of the extension project. The i18n
resource bundle extension is registered in the Component.js
file.
Syntax
"sap.ca.i18Nconfigs": {
"bundleName": "retail.promn.promotioncockpit.<yourExtension>.i18n.i18n"
}
You also have to make the additional changes described in section “Using Another OData Service” - Adjusting the Frontend
You want to add new columns to an existing table, either on the overview screen or on one of the detail screens. Be aware that you first have to create another OData service with additional fields and use it in the app as described in the “Using Another OData Service” section. Afterwards, changes have to be made to the following objects (as an example, the enhancement for the table on the overview screen is described):
Implement the extension point S1_ItemsTableLastColumnExtension
from the overview screen S1.view.xml
to add new columns to the table. An empty fragment is created, in which you can insert the new column definitions.
Syntax
<core:FragmentDefinition xmlns:core="sap.ui.core" xmlns:l="sap.ui.layout" xmlns="sap.m"
xmlns:app="http://schemas.sap.com/sapui5/extension/sap.ui.core.CustomData/1">
<Column id="pecColumnExtensionOrg" hAlign="Right" visible="true">
<header>
<Text text="Extension Org" />
</header>
</Column>
</core:FragmentDefinition>
Implement the extension point S1_ItemsTableLastCellExtension
from the overview screen S1.view.xml
for adding the content of the newly defined columns. An empty fragment is created, in which you can insert the new column content to be displayed.
Syntax
<core:FragmentDefinition xmlns:core="sap.ui.core" xmlns:l="sap.ui.layout" xmlns="sap.m"
xmlns:app="http://schemas.sap.com/sapui5/extension/sap.ui.core.CustomData/1">
<Text text="{path: 'ExtensionOrg'}" width="100px" visible="true" />
</core:FragmentDefinition>
In addition, you have to take care about the additional adaptions described within chapter “Using another OData Service” - Adjusting the frontend part.
You want to display additional fields in the header area of the detail screen. Be aware that you first have to create another OData service with additional fields and use it in the app as described in the “Using Another OData Service” section. Afterwards, changes have to be made to the following objects:
Create an implementation of the extension hook method extHookAfterOnInit
from the Main.controller.js
file in your extension project within MainCustom.controller.js
and enhance the S2 data provider accordingly (name of entity types, select fields), if required.
Implement the extension point S3_DetailFormNewLabelExtension
of fragment S3Detail_Form.fragment.xml
. An empty fragment is created, in which you can insert the fields. Furthermore, the implementation of this extension point is registered in the Component.js
file in your extension project.
To replace screen elements on the different screens (for example, table columns on the overview table, header area of the detail screen), the following extensibility entities are available:
View | Extension Point | Use |
|
| Replace table columns in overview screen |
|
| Fill new defined table in overview screen with content |
|
| Replace |
|
| Replace first status in |
|
| Replace second status in |
|
| Change |
|
| Change first status in |
|
| Change second status in |
You want to replace the entire table on the overview screen with one of your own. Be aware that you first have to create another OData service with additional or other fields and use it in the app as described in the “Using Another OData Service” section. Afterwards, changes have to be made to the following objects:
Create an implementation of the extension hook method extHookAfterOnInit
from the Main.controller.js
file in your extension project within MainCustom.controller.js
and enhance the S1 data provider accordingly (name of entity types, select fields), if required.
Implement the extension point S1_ItemsTableColumnsExtension
from the overview screen S1.view.xml
to replace the table columns. An empty fragment is created, in which you can insert the new column definitions.
Implement the extension point S1_ItemsTableCellsExtension
from the overview screen S1.view.xml
to replace the content description of the newly defined columns. An empty fragment is created, in which you can insert the new column content to be displayed.
You want to replace the object header attributes for the items in the master list. Be aware that you first have to create another OData service with additional or other fields and use it in the app as described in the “Using Another OData Service” section. Afterwards, changes have to be made to the following objects:
Create an implementation of the extension hook method extHookAfterOnInit
from the Main.controller.js
file in your extension project within MainCustom.controller.js
and enhance the S2 data provider accordingly (name of entity types, select fields), if required.
Implement the extension point S2ProcStepObjHeaderAttrExtension
from the master screen S2ProcessSteps.view.xml
to replace the object header attributes. An empty fragment is created, in which you can insert the new attributes.
Alternatively:
Implement the extension point S2ProcStepFirstStatusExtension
from the master screen S2ProcessSteps.view.xml
to replace the first status attribute of the object header. An empty fragment is created, in which you can insert the new first status.
Implement the extension point S2ProcStepSecondStatusExtension
from the master screen S2ProcessSteps.view.xml
to replace the second status attribute of the object header. An empty fragment is created, in which you can insert the new second status.
You want to replace the object header attributes for the selected item in the detail screen. Be aware that you first have to create another OData service with additional or other fields and use it in the app as described in the “Using Another OData Service” section. Afterwards, changes have to be made to the following objects:
Create an implementation of the extension hook method extHookAfterOnInit
from the Main.controller.js
file in your extension project within MainCustom.controller.js
and enhance the S3 data provider accordingly (name of entity types, select fields), if required.
Implement the extension point S3DetailObjHeaderAttrExtension
from the fragment S3Detail_ObjectHeader.fragment.xml
to replace the object header attributes. An empty fragment is created, in which you can insert the new attributes.
Alternatively:
Implement the extension point S3DetailFirstStatusExtension
from the fragment S3Detail_ObjectHeader.fragment.xml
to replace the first status attribute of the object header. An empty fragment is created, in which you can insert the new first status.
Implement the extension point S3DetailSecondStatusExtension
from the fragment S3Detail_ObjectHeader.fragment.xml
to replace the second status attribute of the object header. An empty fragment is created, in which you can insert the new second status.
Adjusting Header and Footer refers to the possibility to overwrite the use of Jam, Titles, Buttons, etc. on the overview screen as well as on the detail screens. These settings need to be made twice; once in the overview screen controller (see base class PECBaseFSController.js
) and once in the master detail view controller, depending on the selected issue category (see PECBaseDetailController.js
).
Changes have to be made to the following objects:
Create a controller enhancement for S1.controller.js
with an empty controller (new file S1Custom.controller.js
in your extension project)
Check component.js
file of your enhancement project regarding the registration of your custom controller:
Syntax
"sap.ui.controllerExtensions": {
"retail.promn.promotioncockpit.view.S1": {controllerName:
"retail.promn.promotioncockpit.<yourExtension>.view.S1Custom" },
}
Define the hook method extHookSetHeaderFooterOptions
in your custom controller (S1Custom.controller.js
), which is used to overwrite existing information and action triggers and as well to add new ones. To change something, object oOptions
has to be adjusted. Within the standard app these options are provided:
- Jam-Integration (-> oJamOptions
)
- For adding new buttons in the footer area, you can add new buttons to the button list of parameter oOptions
. Alternatively, you can remove properties of parameter oOptions
, if you do not support the actions of the standard delivery.
Syntax
extHookSetHeaderFooterOptions: function(oOptions){
oOptions.buttonList = [ { sId : "BT_YesButton",
sI18nBtnTxt : "Yes button",
onBtnPressed : function() { <any coding> }},
{ sId : "BT_NoButton",
sI18nBtnTxt : "No button",
onBtnPressed : function() { <any coding> }}
];
}
Changes have to be made to the following objects:
Create a controller enhancement for all S3<ProcessStep>.controller.js
with an empty controller (new file S3<ProcessStep>..controller.js
in your extension project), for which customer-defined changes to the header/footer area are required
Check component.js
file of your enhancement project regarding the registration of your custom controllers
Define the hook method extHookSetHeaderFooter
in your custom controllers, which is used to overwrite existing information and action triggers and as well to add new ones. To change something, object oOptions
has to be adjusted. Within the standard app these options are provided:
- SAP Jam integration (oJamOptions
)
- Title for the detail screen (sI18NDetailTitle
)
- Button for triggering action (oEditBtn
)
- Other buttons, contained under the “Open In..” button (buttonList
)
Syntax
extHookSetHeaderFooter: function(oOptions){
var that = this;
oOptions.buttonList = [];
oOptions.buttonList.push({
sId : "BT_CommonButton",
sI18nBtnTxt : "Common button",
onBtnPressed : function() { <any coding> } });
oOptions.buttonList.push({
sId : "BT_NewLiaButton",
sI18nBtnTxt : "Lia button",
onBtnPressed : function() { <any coding> }} );
oOptions.buttonList.push({
sId : "BT_OpenIn",
sI18nBtnTxt : retail.promn.promotioncockpit.utils.TextUtil.getText("BUTTON_OpenIn"),
onBtnPressed: jQuery.proxy(that.createActionsheet, this) });
},
createActionsheet: function(event){
this._oActionSheet = new sap.m.ActionSheet({placement: sap.m.PlacementType.Top });
var oButtonListing = new sap.m.Button({
text: "NewLiaPerformListinm",
press: function() { <any coding> } });
// Add Button perform Listing
this._oActionSheet.addButton(oButtonListing);
this._oActionSheet.openBy(event.getSource());
}
All these new buttons will be shown on a specific detail view only, to which the concrete controller belongs to. If the same button/action need to be offered on other detail views, there is a way to implement the same extension hook method extHookSetHeaderFooter
as an extension of the base controller, from which all view detail controllers inherit.
Create a new file PECBaseDetailController.js
in the view folder of your extension project and define an extension for the hook method extHookSetHeaderFooter
of the PECBaseDetailController.js
file from the standard delivery
Syntax
jQuery.sap.declare("retail.promn.promotioncockpit.<yourExtension>.view.PECBaseDetailController");
jQuery.sap.require("retail.promn.promotioncockpit.view.PECBaseDetailController");
retail.promn.promotioncockpit.view.PECBaseDetailController.prototype.extHookSetHeaderFooter =
function(oOptions) {
oOptions.buttonList = [];
oOptions.buttonList.push( { sId : "BT_CommonButton2",
sI18nBtnTxt : "Common button 2",
onBtnPressed : function() { <any coding> }}
);
};
Create an empty controller extension of the master list S2ProcessSteps.controller.js
and require the PECBaseDetailController.js
of the extension project, which overwrites the empty hook method of the standard base detail controller with the function defined in the first step
Syntax
jQuery.sap.require("retail.promn.promotioncockpit.<yourExtension>.view.PECBaseDetailController");
sap.ui.controller("retail.promn.promotioncockpit.<yourExtension>.view.S2ProcessStepsCustom", {
};
This cannot be done in an early point in time like in Component.js
or MainCustom.controller.js
, when the extension project is loaded, because necessary components are not yet loaded, which are needed in the base detail controller during load of the detail controllers. Keep also in mind that this extension might be overwritten by a concrete detail controller like for listing or price activation issue. Then, these concrete implementations overwrite the extension of this central detail controller.
To add a new process step, changes have to be made in the OData service resp. Virtual Data Model as well as in the UI. Be aware that you first have to create another OData service with new entity types related to the new process step and use it in the app as described in the “Using Another OData Service” section.
In general, changes in OData services are described in the “Using Another OData Service” section. The following information may also be useful:
Each process step has 3 digits, starting with a capital letter. For customer enhancements in particular, a “Z” or “Y” should be used as the capital letter. This new code value can be used as part of the input parameter for the underlying query (input parameter P_Processstep
of the standard delivery).
Copy the existing reuse views RetailPromnPreparationIssues
and RetailPromnPreparationItemIssues
in a custom package.
Adjust the reuse views located in your package with a customer-specific logic, to determine the due, overdue, and error situations of your process step. To do this, you can create new calculated columns in view node PromoHeaderItemJoin
. Use the existing calculated columns such as PurPriceActvtOverdueDate
, PurPriceActvtDueDate
, PurPriceActivationIsNotCmplt
, PurPriceActivationHasError
, PurPriceActivationIsDue
, PurPriceActivationIsOverdue
of the process step purchase price activation as an example. Propagate your new fields to the semantic level. In the view node FilterOutIssues
you have to consider your new key figures in the existing filter expression
Repeat the second step for the item view RetailPromnPreparationItemIssues
located in your package.
Copy the existing query view RetailPromnPrepIssuesTileQuery
in a custom package.
Adjust the query view located in your package, and propagate the new fields to node InputParamConsideration
. In this node the indicators are recalculated by considering the input parameters P_ProcessStep
, P_Urgency
, and P_ErrorCategory
. Use the existing calculated columns such as PurPriceActivationHasError_1
, PurPriceActivationIsDue_1
or PurPriceActivationIsOverdue_1
of the process step "purchase price activation" as an example
Propagate your new fields to the next node. In the view node FilterOutIssues
you have to consider your new key figures in the existing filter expression
Propagate your new fields to the node NumberCalc
. Consider the new key figures in the formulas of PromotionContainsError
, NmbrOfDueIssInPromn
, NmbrOfOverdueIssInPromn
, NmbrOfOverdueErrorsInPromn
, and NmbrOfDueErrorsInPromn
Repeat all steps from the Tile query view for query view RetailPromnPrepIssuesQuery
.
Copy the existing query view RetailPromnProccessStepsQuery
in a custom package.
Adjust the query view located in your package and propagate the new fields to node InputParamConsideration
. In this node the indicators are recalculated by considering the input parameters P_ProcessStep
, P_Urgency
, and P_ErrorCategory
. Use the existing calculated columns such as PurPriceActivationHasError_1
, PurPriceActivationIsDue_1
, or PurPriceActivationIsOverdue_1
of the process step Purchase Price Activation
as an example
Propagate your new fields to the next node. In the view node FilterOutIssues
you have to consider your new key figures in the existing filter expression
Create a new projection pair for your process step, just like the pair ProcessStepPpa
and FilterOutNoIssuesPpa
for the process step Purchase Price Activation
. Introduce a new abbreviation (maximum 3 digits) for your process step
Include your new process step in the union UnionProcessSteps
Create a new detailed query view for your process step, to determine the promotion items that have your issue. You can use query view RetailPromnPurPriceItmIssuesQuery
as an example.
Copy the existing OData service kpi.xsodata
into a custom package. Replace the package path sap.hba.apps.rtl.s.v
with your own package path and also replace the query name
Copy the existing OData service pec.xsodata
into a custom package. Replace the package path sap.hba.apps.rtl.s.v
with your own package path and also replace the query names for RetailPromnPrepIssuesQuery
and RetailPromnProcessStepsQuery
with the names of your query copies. Finally, add the new master/detail query view to the OData service
The standard service list defined in the Configuration.js
file needs to be changed in your extension project if you plan to replace the existing model promoprocsteps
on the master detail view with a new model, or you plan to add a new model for the new process step related detail view (see section “Using Another OData Service”). For the latter, you cannot use the S3DataProvider
class and you must implement your own code to work with a third model.
You have to enhance retail.promn.promotioncockpit.utils.ProcessStepsConstants
using the methods addProcessStepToList
and addProcessStepToMap
.
- Object PROCESS_STEPS_MAP
- Array PROCESS_STEP_LIST
(3-digit abbreviation)
Some texts, such as field labels or table column headers have to be inserted into the respective enhancement i18n-property-files
Enhance the properties XS_ENTITIES
and queries in retail.promn.promotioncockpit.model.S3DataProvider
Create a new detail screen for the new process step, in accordance with other process step-related detail screens. Use the naming convention S3<yourName>.view.xml
Register the new detail screen within the routing definition in the retail.promn.promotioncockpit.Component.js
file
Syntax
"<Zxx>StepDetail" : {
pattern : "<Zxx>/Promotion/{promoId}/ProcessSteps/{processSteps}/{contextPath}/Urgency/{urgency}/ErrorType/{errorType}",
view : "S3<yourName>",
viewLevel : 3
},
That is the minimum that needs to be done. Of course, it is possible that other cases could arise (for example, the new process step cannot be overdue, which would mean that methods overdueDays
and isOverdueDateVisible
in Formatter.js
would also have to be overwritten).
For a general description of the extensibility options and procedures of Fiori apps, see Extensibility.