This is a four-part blog:
1. Introduction and Analysis of the standard oData Service
2. Fiori enhancement approaches
3. Fiori extension with the SAP Web IDE
4. Extension of the standard oData Service (this part)
4 Extension of the standard oData Service
4.1 Requirement
The behaviour of using a star ‘*’ to indicate externally-visible item texts is standard for print forms, however this app will only be used internally so it makes sense to show all items texts, regardless of whether they start with a star. To achieve this I decided to create a custom Item Text field, to be filled from BSEG-SGTXT with some custom code.
To do that I first needed to enhance the standard oData service – to do that I followed the approach explained by Masayuki Sekihara here:
How to Guide: SAP Fiori Extensibility - Adding Custom Felds in OData
I couldn’t see any suitable enhancement point in the Fiori Apps Library, so I navigated from there to SAP Help. In SAP Help it appears that entity PaytProposalInvoice can be enhanced to add custom fields:
Based on Masayuki’s guide I completed the following steps:
4.2 Step 1: Extend the ABAP DDIC extension structure
Data element SGTXT was copied to customer data element ZZSGTXT, and the description and help text were changed to explain how this field differs from standard:
This was then added to the extension structure provided, by means of an Append structure and an Include structure (as per our development standards - you could just put the fields directly in the Append if you don't need to use the structure elsewhere):
4.3 Step 2: Extend the OData Entity in the GW Model Provider
Package ODATA_REVISE_PAYMENT_PROPOSAL contains the Model and Data Provider classes for this Odata service.
There is no BAdI available in this case to extend the Model Provider class. In the absence of a BAdI it seems there are two options for extending the Model Provider as explained by Raymond Zhang here.
· Use SEGW to extend the entity definition. Having done this the transaction can then regenerate the MPC code automatically.
· Code the changes directly. For example the MPC_EXT class in this class already contains a redefinition of the DEFINE method. I could use an implicit enhancement to add custom code to this.
I chose to use SEGW where I added a field as follows:
After Generating Runtime Objects, the MPC class CL_FAP_REVISE_PAYMENT_MPC contained the following code:
4.4 Step 3. Fill the custom fields in the GW Data Provider
Having defined my custom field, I now want to fill it with data. Again, in this case I don’t have a BAdI available. As highlighted in the Fiori Apps Library, my custom code must be added to method:
CL_FAP_REVISE_PAYMENT_DPC_EXT-> PAYTPROPOSALINVO_GET_ENTITYSET
This method is already a redefinition of that from the parent class method, so rather than redefining I used an implicit enhancement at the end of the method. The code simply reads BSEG-SGTXT for all entries in the entity set, buffering the results in a table (to avoid repeated select singles). It then loops through the entityset and either copies any existing Item Text to the custom field, or looks up the Item Text in the buffer table and copies that to the custom field instead.
ENHANCEMENT 1 ZEI_REVISE_PAYMENT. "active version
*----------------------------------------------------------------------*
* DESCRIPTION:
* Fill a custom field with Item Text from BSEG.
* This is necessary because the standard logic takes data from REGUP,
* which only contains Item Texts if they start with * (meaning external).
*
* AUTHOR: Roger Sainsbury SAP
* DATE : 15/07/2016
*
*----------------------------------------------------------------------*
* CHANGE HISTORY
* Date Changed By Chng ID Description
*----------------------------------------------------------------------*
* <dd/mm/yy> <user id> <RFC No> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
*----------------------------------------------------------------------*
types:
begin of ty_sgtxt,
BUKRS type bukrs,
BELNR type FAP_RPP_BELNR,
GJAHR type gjahr,
BUZEI type buzei,
SGTXT type sgtxt,
end of ty_sgtxt.
data:
lt_sgtxt type hashed table of ty_sgtxt
with unique key BUKRS BELNR GJAHR BUZEI.
if lines( et_entityset ) > 0.
* Read item text from BSEG for all Document Items
select BUKRS,
BELNR,
GJAHR,
BUZEI,
SGTXT
from BSEG
for all entries in @ET_entityset
where bukrs = @ET_entityset-bukrs
and belnr = @ET_entityset-belnr
and gjahr = @ET_entityset-gjahr
and buzei = @ET_entityset-buzei
and sgtxt <> @space "Item text is not blank
into table @LT_sgtxt.
if sy-subrc = 0.
loop at et_entityset assigning FIELD-SYMBOL(<ls_entityset>).
if <ls_entityset>-sgtxt is initial.
* No text was selected as standard; check if a text was selected from BSEG above
read table lt_sgtxt assigning FIELD-SYMBOL(<ls_sgtxt>)
with table key bukrs = <ls_entityset>-bukrs
belnr = <ls_entityset>-belnr
gjahr = <ls_entityset>-gjahr
buzei = <ls_entityset>-buzei.
if sy-subrc = 0.
* Item text found in BSEG - copy it to the custom field
<ls_entityset>-zzsgtxt = <ls_sgtxt>-sgtxt.
endif.
else.
* If the standard text field contains a text (e.g. that begins with *)
* then just copy it.
<ls_entityset>-zzsgtxt = <ls_entityset>-sgtxt.
endif.
endloop.
endif.
endif.
ENDENHANCEMENT.
Note that in hindsight I could instead have just changed the content of the standard Item Text field, rather than populating a new custom field. The oData service is designed specifically for this app, so we might reasonably expect that changing a standard field here should not have an effect anywhere else.
4.5 Add the new column to the Fiori UI using the Web IDE
In my case I had already enhanced the Fiori app to add the standard Item Text column, so only minor changes were required to substitute my new custom column instead.
The revise app was then re-deployed back to the front-end Fiori Gateway system as described earlier in Part 2.
4.6 Result
To re-test, for document 1900000211 we removed the stars from the Item Text:
As required the app now shows the Item texts correctly, regardless of whether they begin with a star or not:
Conclusion
Hopefully this blog provides a useful reference of extensibility techniques to consider, and steps to follow, to extend a Fiori app. In summary we’ve seen there are five enhancement techniques to consider for the UI:
· Customising in the IMG
· Personalisation
· Runtime Adaptation (RTA)
· ‘Custom Fields and Logic’ Fiori app
· Web IDE
Whilst to enhance the oData service there were three steps:
1. Extend the appropriate ABAP structure to add any custom / additional fields required.
o This is achieved by implementing an APPEND in the standard extension structure provided.
2. Extend the OData Entity in the GW Model Provider. This could be achieved by:
o Implementing a BAdI if available. OR
o Using transaction SEGW to extend the entity definition. OR
o Coding directly by re-implementing the appropriate method, or by implementing an implicit enhancement.
3. Fill the custom fields in the GW Data Provider. This could be achieved by:
o Implementing a BAdI if available. OR
o Coding directly by re-implementing the appropriate method, or by implementing an implicit enhancement.
Remember these blogs have only described my personal experience on this particular S/4 HANA release (1511 OP FPS1). This is a fast-moving area and it may be that on a different release there will be different options available. Feel free to share your own thoughts or experiences of this topic through the comments.
- SAP Managed Tags:
3 Comments
