Problematic development of Screen Personas 3.0 using SAP Transports

[Marçal_Oliveras]

Hi,

I'm writing this in order to find out what should be the proper way to develop Screen Personas objects in a DEV environment without master data and then transport to Q&A and Production using ABAP transports.

The scenario is the following: Personas requires master data when we try to create flavors and scripts because we need to simulate user interaction in order to identify fields or generate action scripts.Our SAP development environment does not have any data (just something minimal), therefore we are not really able to reproduce most of the actions the user can do in production.

We have a secondary client with some data and also a quality environment with almost the same configuration than production. We can develop personas flavors there, yes, but then we are not able to add them to a transport because all transports are always created for the development environment with no data.

Given this situation, I tried the following:

1. Develop in Quality environment or the DEV Client with some data
2. Export flavors and other objects in a ZIP file
3. Import ZIP file objects in the DEV environment
4. Add the objects to a transport.

But after doing this, the objects become permanently locked for editing in any environment and client different than the one of the transport. I debugged the standard code myself and I could see that it determines the original system based in the last existing transport where the object ID is assigned. So once an object is linked to a transport, the original system will always be the one for the transport and then Personas does not allow to edit from a non-original system.

So here I´m now. I couldn't find a way to properly develop Personas screens and at the same time use the SAP Transport mechanism.

Anyone could help me? Maybe I'm missing something?

Regards,

Marçal

[tamas_hoznek · Accepted solution]

Generally speaking, it is very difficult (or sometimes nearly impossible) to perform sensible development in a client where there is no data or the configuration is at least not close to what is present in a QA or PRD environment. How would you expect developers to be able to code or unit test what they are doing if there is no data so that they can run through the transaction properly?

This is the same for Personas, or better said, it is even more important to have proper data. Otherwise you cannot make sure that the screen appears the same way like in other systems, and cannot customize objects that don't even show up on the screen etc.

In my opinion, you should get sufficient data into your development client where your transports are initiated from. This will make all developers' life easier, not just those who are creating Personas flavors. You could say that in case of ABAP programs, screens, classes etc. it is possible to code in one client and test in another - but that's only because those objects are client-independent while the Personas flavors are not. Even in this case, the developer has to log on to a different client for testing, whereas if they had the data right there in the development client, they wouldn't need to do that extra step.

However if you would happen to deal with a client-dependent development object (say a SmartForm or something similar), then the situation is really not different than in case of Personas. You have to copy your object into another client, unit test it and if there is a problem, make the change in the originating client, then re-copy... you get the idea. It is just not convenient that way.

Every time when I worked on a project where the DEV environment didn't have good data, the process was a pain and it took much longer than it would have with sufficient data in the same client. I really don't see a compelling reason for setting up the DEV box this way.

[Marçal_Oliveras · Accepted solution]

Hi Tamas,

In general I agree with you, but a lot of customers where I worked had the same problem I'm facing right now in the DEV environment. They do have some data but it doesn't cover all the possible scenarios. When this happens you are forced to test in Q&A or in another client that has data (this one is my current scenario).

The part I do not agree with you is that personas is like any other client-dependant object like SmartForm. It is not, because in order to create a script you need to simulate user interaction and also be able to access the screens that require some master data. If it was not for this, I would do as you say, develop in "empty" client and copy to the one with data using SCC1 transaction (quite dangerous transaction to import transport changes to a client).

[former_member188433 · Accepted solution]

I have similar observations to those provided by Marcal and Krishna.  We have a landscape that is very similar to the one that Marcal describes.  We have had to develop our own workarounds to make transports work.  The biggest help for us has been to delete the object in the target system before transporting or doing a Personas export/import:
1. We develop in our DEV client that has test data.

2. When ready to transport, we must first export/import into the DEV client that allows client-dependent transport (deleting the flavors in the target client first).

3. We build a transport and move to QAS and PRD (deleting in the target system before importing).

The client-dependent nature of Personas objects seems in conflict with the generally client-independent nature of more traditional ABAP development.  This is ironic to me because Personas flavors (client-dependent) are based on gui screens (client-independent). 

Best Regards - Jeff

[tamas_hoznek · Accepted solution]

Actually, the SmartForm example is pretty fitting because similar to a Personas flavor, it is rather difficult to work on a form when there is no representative data in the development client. In case of Personas this is even more so.

If you lack the data, then creating a form will be significantly more challenging as well. Maybe not impossible like in some cases with a Personas flavor, but making sure the data appears properly when there is nothing to display is at least problematic.

I think you misunderstood me because I didn't say that you should develop in an empty client. On the contrary, I say that this is a pretty strong argument for persuading "the powers that may be" and get the necessary data into the development client.

The bottom line is that developing anything (even client-independent objects as well) is much simpler when the development client is filled with a meaningful and representative set of data mimicking the QA/PRD environment. If a company is not willing to set up their system like this, they have to accept the fact that development will become more cumbersome and will take more time due to the extra hoops developers have to go through, eventually dealing with transports and associated delays. Then this can be compounded with additional restrictions in the QA environment if certain debugging authorizations are restricted.

[tamas_hoznek · Accepted solution]

Personas flavors are not just based on the client-independent GUI screens but also depend on the data they are created for.

The client-dependent nature of Personas flavors actually has the benefit of being able to create different flavors for clients that are used for different purposes. The way a Personas flavor is built may make sense in one client where the necessary data the flavor expects and relies on is available. If flavors were client-independent, then in another client where such data is not present, the same flavor wouldn't make sense or wouldn't necessarily work properly.

In your scenario, I'm not sure why do you need to delete in the target client first. The GUIDs remain the same and the transport should just overwrite any already existing flavor so this seems to be an unnecessary step.

[Marçal_Oliveras · Accepted solution]

Hi Jeff,

Why do you delete the flavors in the target client before importing the transport? I expected them to be overwritten, did you face any conflict?

So far I'm plan to follow the same strategy than you. I did a test and it works but there is still this scenario where deleting an object has to be done directly in the client with the transport otherwise it won't be deleted when importing to other environments. This situation can be quite confusing for some developers...

[Marçal_Oliveras · Accepted solution]

Hi Tamas,

Thanks again.

I think that I don't have any chance to convince my company to have the DEV client where transports are created with proper data and configuration. Also it will be difficult for me to justify too much time in a project dedicated to dealing with transports, but I guess I will have to live with it.

So far I can't find a 100% satisfactory way to work with Personas within our landscape.

[former_member188433 · Accepted solution]

Hi Marcal - We were seeing various rendering issues in the target after copying a flavor that already existed in the target.  We never saw the problem with new flavors.

The "delete before transport" does require additional planning so that we do not disrupt end users.

We do the delete as a manual processing step before importing the transport (or before running the Personas import).  This requires Basis support in QA and Prod. 

Best Regards - Jeff

[tamas_hoznek · Accepted solution]

I understand your constraints and sympathize with your situation, but this has really nothing to do with Personas as a tool. It's not the fault of Personas that development is awkward / not possible, if the necessary data is not available in the development client.

This discussion makes it sound like there was a conceptual issue with Personas in regards to transports, which is not the case.

[Former Member]

To overcome this challenge, we are exporting from QA and importing to production -> we do not use transports for this. It works well.

If you want to safeguard your flavor archive, use a DMS or extra import to your DEV as well.

Otherwise you'd need another "flavor development" client with business data and a complex transport chain to ensure integrity.

[Marçal_Oliveras]

Thanks Merten,

Yes, we actually have this other client in DEV with some data, but it is not allowed for us to create transports there...

Regarding not using transports at all, it is of course a valid option, but I see a couple of problems: you can't ensure integrity since one object can be deleted in QA and then this won't be imported to production, so basically you have to remember to only mark as deleted but never delete from database, and new employees may not be aware of that... The other is that SAP transports was something that made SAP a very strong platform in its origins, I don't like to start playing with ZIP files in 2016 even it may work, but it's not the optimal solution.

[kammaje_cis]

Marcal,

I completely agree. After going through a cycle of moving Personas from Dev to QA, it was not a smooth experience. I expected a better integration with Transports.

[tamas_hoznek]

Krishna,

How exactly would you imagine the transport system to behave? I believe the transport mechanism implementation for Personas is quite good and don't know what do you mean by "better integration".

If you have the usual DEV-QA-PRD landscape, everything should work smoothly. What was the problem you experienced, compared to how other regular development objects behave in your environment?

[Marçal_Oliveras]

I found note https://launchpad.support.sap.com/#/notes/2273808 in order to disable original system check.

This is not enough because I could verify that now I can delete a flavor in the non original system client and not adding it to a transport... meaning that I could have misaligned environments.

[clemens_gantert]

Hello,

After you imported your flavor into DEV through zip file and after you put it into a transport request in DEV, if you're not able to change the flavor in DEV, we would consider this a defect. Please open a CSS ticket for it.

If you transport this flavor now from DEV to QA and would like to edit it in QA then my suggestion would be to clone the flavor in QA, change the clone and import it into DEV and so on.

Best Regards,

Clemens

[Marçal_Oliveras]

Hi Clemens,

Once I import in DEV and I add the objects to a transport, I can edit in DEV (at least the client where the transport was created) but not in Q&A anymore after the transports hits Q&A.

If I clone the flavor in Q&A, I'm afraid some stuff will stop working since scripts use flavor ID sometimes.