Skip to Content
Technical Articles

Three Improvements That Make Forms Development in SAP S/4HANA Easier

SAP S/4HANA brought lots of functional changes to applications, but development cross topics such as the development of print forms were improved as well. Here are three points that will help you when developing your Adobe forms in the new SAP S/4HANA output management:

 

1. Testing changes instantly with the APOC_RENDER_DOCUMENT report

It has always been cumbersome to ‘just quickly test’ even minor changes made to forms.

Usually this involves:

  • once: setting up test data (some business document) in the appropriate transaction and
  • recurring: going through a number of steps to get the system to actually trigger a new output.

Some applications may even need a new business document to be created for each test (e.g. by copying and slightly modifying another business document) – resulting in lots of necessary steps just to see that small change you made.

With SAP S/4HANA this challenge has been solved for gateway-based SAP Interactive Forms by Adobe:

SAP S/4HANA Output Control provides the report  APOC_RENDER_DOCUMENT which enables the form developer to instantly trigger rendering of the specified form template with actual business data:

This report simulates the standard rendering process of SAP S/4HANA output control. Just the document type (Application Object Type and Output Type) must be provided, along with the rendering parameters (like form name, locale settings and – optionally – a master form name). No going through the application’s transactions or Fiori app anymore!

Once the rendering is processed, a ‘Save As’ window appears and lets you save the newly rendered form and review your form changes within seconds. You can also make use of the ADS trace for detailed analysis.

This has become possible only because of the harmonized output management in SAP S/4HANA and the fact that we do not have individual print programs for each application anymore.

A disclaimer applies:

  • The report isn’t official, there is no documentation and not guarantee that it will stay the same or even exist in future. It is originally meant for internal analysis.
  • For this reason, there is no customer support for it and we cannot expect that it was tested as thoroughly as official functionality.

 

2. Be aware: text modules are not directly supported in the new SAP S/4HANA  output management

With traditional SAP Interactive Forms by Adobe in ECC you have the choice of using either SAPscript (so10) or Smartforms text modules. They are used a lot for terms & conditions pages or simply for the legal footer that is usually found on the bottom of the first page of a customer-facing document.

In addition to your own text modules as described in the last paragraph you may want to access long texts such as item/material descriptions from standard applications by giving the appropriate IDs and names in the form’s context. The rendering logic then automatically retrieves the text modules or long texts directly from the database, even including some formatting.

With the introduction of the new SAP S/4HANA output management, the form context is now inaccessible since all data provided to the form layout is passed through the form’s Gateway service.

This also means that there is no automatic support for text modules anymore. Any text module that you want to display on the form must be read in the code behind that Gateway service, e.g. through a function module such as READ_TEXT or by reading directly from the database.

For some texts like ‘Terms and Conditions’ that usually have to look nice on paper, this also raises the question which kinds of rich text / formatting tags are supported by text fields in your layout. Here is a list of formatting tags that you can use in HTML style:

  • A
  • B
  • BR
  • BODY
  • HTML
  • I
  • P
  • SPAN
  • SUB
  • SUP

In summary – if you need text modules on your form while using the new output management, you’ll have to read them yourself and pass the string (if necessary, with formatting tags) via the Gateway service.

Don’t forget to select ‘rich text’ in the text field properties and also check ‘Allow Multiple Lines’!

 

3. Performing WYSIWYG translations in LiveCycle Designer

Translating SAP Interactive Forms by Adobe in ECC is challenging since the context of labels and texts is not visible:

With SAP S/4HANA, this process has changed with the extension of the ‘Maintain Form Templates’ app to include a translation feature – where an XDP layout file can be downloaded just like when editing the layout itself.

Once downloaded, you can open the XDP file in the local LiveCycle Designer, change the labels right where they are and then upload that XDP file into the ‘Maintain Form Templates’ app again.

The system will then look up the IDs of your translated labels and text fields, match your new translation to the original content and save the translation.

The XML translation view remains available in the system for any labels that are not easily translated through the WYSIWYG editor.

This new approach for translating forms finally eliminates the need to interpret an XML file without any context in order to determine the strings for translation.

More information about SAP S/4HANA forms translation changes can be found in Note 2854484 – Maintain Form Template S/4HANA app: Form template translation using Adobe Live Cycle Designer.

 

I hope this article helps you improve your forms development in SAP S/4HANA! Keep in mind that these points apply only to applications that have the new SAP S/4HANA output management activated – and that the first two points require an On Premise installation.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.