Hi all,
we're running S/4 HANA 2023 FP1 on-premise and as part of our clean core strategy, we need to deal with forms as well. As today, we use all available technologies like SAPScript, SmartForms as well as Adobe Forms. For sure, we only stick to Adobe Forms for new forms since several years.
To my understanding, we can use SAP Forms in BTP also on-premise. It will only be a replacement for our on-prem ADS, but there is no need to change any print report or form. So we can still use all the NAST and other stuff available since decades. This only covers infrastructure in my opinion. But what is the difference from a developers perspective?
As we all know, reports are not clean core compliant. This must also be true to print reports you define in customizing. So there will be no print report in future anymore. We actually have no plans to move to cloud but at least I want to be prepared for this. This brings me to my final question
What do we need to consider when it comes to developing SAP Forms in a cloud-ready manner? Where and how should we place our custom logic for custom forms as well as for SAP standard forms (i.e. handling templates for invoices, purchase orders etc.)? How to do this to be able to use the form in both, on-premise as well as cloud?
- do we need to replace the logic from Z-print reports to Z-classes? (we typically do this these days)
- do we need to place custom logic into interface of a form (we do this for standard forms [invoices] to be able to stick to standard print reports)
- anything else we should consider on-premise?
As said, actually there are no plans to move but at least we should be prepared for this. At least we need to refine our development guidelines to reflect any new concept.
Our current approach looks like this:
- in case of totally custom form, any code is handled by dedicated print classes. The classes implement the business logic as well as calling the form FMs
- in case of adopting standard forms, we copy standard form interfaces and add any additional custom code inside this. Same is true for form itself for sure. By this, we can still use standard print reports
- in any case, we try to avoid mixing both concepts. Code should be either in dedicated print class or in interface but not in both.
I hope someone can give me some hints
Patrick
Bluesky
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.