cancel
Showing results for 
Search instead for 
Did you mean: 

How to migrate ABAP with "call sceen" and "call function" to S/4HANA?

TMNielsen
Contributor

Hi

I have read about all the limitations of ABAP in S/4HANA but it is evolving very fast, so it is hard to keep up. Especially I think usage of dynpros and SAP standard function modules can be a problem.

So a couple of question

  1. Is it true, there is no SAPgui in S/4HANA?
  2. What options exist to migrate a program with dynpros
  3. What happens with call of BAPIs and simple functions like READ_TEXT? Can they be migrated with the quick fixes in SAP devlopment tools in Eclipse?

And it would be nice if answers could specify if the answer depends on Steampunk VS Embedded Steampunk. 🙂

Kind regards

Thomas Madsen Nielsen

FredericGirod
Active Contributor

1 As there is a SAPGui special version for S/4, the answer is obviously: No

2 Dynpro exist in S/4, but SAP tries to push you in the Fiori world

3 What is the link between Eclipse and S/4 ? Eclipse works before S/4

TMNielsen
Contributor
0 Kudos

Thanks Frederic for your comments.

When I mentioned Eclipse, I was referring to the Custom Code Migration Tools in RISE witch in Eclipse has "quick fixes" to fix common issues when migrating custom code from ECC to S4/HANA. The reason i asked this question is that I heard gurus from SAP on last years Teched say things like

  • you can't use ABAP dynpro
  • SAPgui is dead - again
  • you can't call function modules
  • you can't make SQL statements on SAP standard tables

Now I have seen a demo of a quick fix tool (in Eclipse) that solved the problem with SQL on SAP standard table so I was wondering if similar quick fixes exist for the problem with calling SAP standard function modules.

Maybe you will now tell me that I can still call SAP standard functions and that would be nice to hear, but I guess this is not best practices - and probably never has been (except for BAPIs), so my question still stands.

Kind regards

Thomas

Sandra_Rossi
Active Contributor
  1. There is SAP GUI in S/4HANA
  2. Create from scratch Fiori, etc.
  3. BAPI, READ_TEXT, etc. still exist
TMNielsen
Contributor
0 Kudos

🙂

I forgot one statement from last years Teched.

  • There is no SE80 in S/4HANA!

Is this also not true?

matt
Active Contributor

I think whoever stated these things is confusing S/4HANA standard with S/4HANA in the cloud.

This from my S/4HANA system:

TMNielsen
Contributor
0 Kudos

HI Matthew Billingham

I guess your are right and It might also just be me that did not understand the core topic of the teched sessions I watched.

Just for clarification - when you say S/4HANA standard - is that the same as S/4HANA on-premise?
Also someone is mentioning S/4HANA public cloud vs S/4HANA private cloud. Is private cloud the same as on-premise?

Can anyone give a link to an overview and comparison of the different S/4HANA options (on-premise, private cloud, public cloud, ....)

Kind regards Thomas

Sandra_Rossi
Active Contributor
PrasanthM
Product and Topic Expert
Product and Topic Expert

Hi Thomas,

In addition to the responses already provided, I would request you to go through the excellent overview provided by boris.gebhardt

Thanks and Regards,

Prasanth

TMNielsen
Contributor

Thank you Prasanth

This is probably the best answer explaining how Cloud ABAP and classic ABAP can co-exist in same on-premise system. Especially interesting is the information that ABAP objects can be changed one by one from Classic ABAP to ABAP Cloud.

I have one more question that you may be able to answer.

I have learned that classic development tools like SE80 is still available in on-premise systems but in cloud environment we will have to use Eclipse. So this raise the question. If we on-premise use embedded steampunk for individual object by choosing ABAP language version "ABAP for Cloud Development", will we then still be able to use classic development tools or must these objects be maintained in Eclipse?

Accepted Solutions (1)

Accepted Solutions (1)

PrasanthM
Product and Topic Expert
Product and Topic Expert

Hi Thomas,

You will still be able to use classic development tools by choosing 'ABAP for Cloud Development' on your on-premise systems. But as a best practice, it is recommended to use Eclipse.

For example, powerful tools like Semi-automatic custom code adaptation for SAP BTP ABAP Environment are available as eclipse addons which helps you to make your legacy ABAP code, cloud ready.

I would also recommend you to go through the ABAP Language FAQ, which was recently published by thomas.schneider

Thanks and Regards,

Prasanth

Answers (1)

Answers (1)

ThFiedler
Product and Topic Expert
Product and Topic Expert

Hi Thomas,

the answer depends on the deployment model of the S/4HANA system.

1.) S/4HANA on-prem or S/4HANA private Cloud

  • SAP GUI is still available, SE80 can still be used
  • You can still use classic UI technologies (Dynpro , WebDynpro...) for your extensions
  • Embedded Steampunk provides an additional development approach for upgrade-stable and cloud-ready custom development. It is based on a limited ABAP feature set (e.g. no dynpro) and the usage of relased APIs (e.g. no SAP function modules)
  • So it is a hybrid model of legacy code that can still use all ABAP features and the new Cloud-like model.
  • Migration from legacy to new model is possible.

2.) S/4HANA public Cloud

  • SAP GUI is not available, SE80 is not available, ADT is the only available IDE for ABAP
  • You cannot use classic UI technologies, Only Fiori UIs with RAP are possible for customer extensions
  • Embedded Steampunk plus Keyuser Tools are the only option for In-App customer extensions plus Side-B<-Side extension in SAP BTP
  • No hybrid model possible, Legacy code (incl. old technologies) is not possible
  • Legacy code needs to be migrated to Embedded Steampunk

Concerning the migration of legacy code we offer tool support like the already mentioned Quick fixes in Eclipse. But the migration of Dynpro-based UIs with ALV and Reports to the new RAP based Fiori-model is not so easy and can most likely not be automated.

Regards,

Thomas.