SAP Personas : Important points to consider
This blog post covers the topics which I came across when I developed my First screen personas application. There were some road blocks that we faced and how we overcame them.
- Understand the transaction screen
- Device Resolution
- Client for development
- Collect enough information from Functional expert
- Implement personas health check notes in case of any error/issue
- Screen/Control Overwrite
- In case you get blocked
- Using function module
Understand the SAP GUI transaction screen:
Problem : We were working on “MIGO_GI” transaction screen to simplify it. there are two buttons in this screen “Header Expand/collapse” and “Detail Expand/collapse”. We stared with both these sections expanded and did all the changes within that screen. but later we observed that , when these sections are collapsed , the standard screen renders and our changes are not visible on the screen anymore.Also there were two drop downs at top left of the screen, which play very important role in which screen elements will be rendered on screen.
on load of screen, we verified if both the sections are expanded and then only proceeded with the further operations.
Most of the SAP GUI transaction screens, have these ‘Expand’, ‘Collapse’ ,’Header’ ,’Details’ button, which toggle different sections of the screen. the IDs of the most of the controls change when these buttons are clicked. So in a way, the screen element you wish to edit, is not the same when the header panel is expanded and when closed. If your control ID is changing on Expand/collapse or due to any other action on screen, you might need to consider Control overwrite rule.
Device resolution & Quick prototyping:
Ask for resolution of device on which the app will be used. Create quick initial prototype and test it on that device first to get idea how it looks /renders. Check what is maximum height and width you can utilize without having user to scroll.
Client for development:
Generally, the client that is used for development does not have sufficient data. so you might have to develop the screen flavor in the client which has enough data. For screen personas development, we need that screen element to be visible on screen first in order to make any changes to it.
Collect enough information from Functional expert:
As I mentioned I previous point we need that screen element to be visible on screen first in order to make any changes to it. you should have enough data , and know steps to make that screen element available on screen. Get a document from functional expert which enlists this “data and steps”, for all the screen elements that need to be modified.
What user selects in SAP GUI screen affects your developed flavor too.
example: We were developing flavor for MIGO_GI tcode, which allows Goods issue only for
1st drop down: “Goods issue” ( lets say it has id FieldID1) and
2nd drop down: “Order”. ( lets say it has id FieldID2)
We removed other options from the drop down and made the fields “read only”.
but when user logs in to “MIGO_GI” tcode in SAP GUI screen, and uses the standard screen and selects any other options from down . the screen renders different drop downs altogether.
and the field ids does not remain same.
so in that case
1st drop down has id : FieldID5 and
2nd drop down has id : FieldID7
and when user opens the “flavor” developed, it does not find the desired fields ( with ID FieldID1 & FieldID2). so the screen does not render properly.
so in this such cases: consider Control overwrite rule
Implement personas health check notes in case of any error/issue
Whenever you encounter any error/issue which does not seem related to your scripts written , Implement personas health check notes and check after some time as they need some time to reflect. issue like : the screen elements , behave differently in different environments. , any network call failing etc.
In case you get blocked :
While writing script for “onScreenLoad” event, do not attach it to the event directly without testing. Before attaching, make sure it does not have any error. ( otherwise, if you have made the flavor as “default” and as soon as screen loads, the event will be triggered and the script which might have error will be executed and it will block you from developing further as the Slipstream engine editor will not open due to that error in script)
If by chance above problem occurs, then go to personas admin t-code /PERSONAS/ADMIN, and delete latest version of your flavor. You might lose some changes that you have recently done, but you will be able to continue with development. In the same Transaction , you can also change your default flavor.
Using function module:
ABAP team will create a function module. We need to add it to whitelist mode in personas admin transaction code /PERSONAS/ADMIN. and these changes we need to add to customizing transport request.
You can debug the Personas Scripts in the same way we debug the fiori app’s code. Using breakpoints ,console etc.
Hope you find it helpful .Let me know if you have any questions about any point mentioned above. Will cover these points in further details in future blog posts
Thank you all,