Discover the key technical distinctions between Adobe Forms created through the Fiori app ‘Maintain Form Templates’ (fragment-based) and DDIC-based Adobe Forms created through transaction SFP.
Choosing the right approach depends on several factors:
-
The SAP S/4HANA version you are using
-
Whether a standard form template exists in the Maintain Form Templates app
-
Whether a standard OPD configuration is available for your process
-
Whether you need to reuse layout objects like headers, footers, or logos across multiple forms
Let’s explore each difference in detail.
1. Data Source
In a DDIC-based Adobe Form, the data source is represented by an ABAP interface. You can write data logic in the form calling program or in the code initialization section of the interface.
In contrast, fragment-based Adobe Forms use a Gateway model (OData service) as the data source instead of an ABAP interface. This is a key advantage, as it allows you to maintain and design forms without having backend ABAP access.
Tip: You can download the layout and binding through the Maintain Form Templates app and open them locally in Adobe LiveCycle Designer for design changes, no backend required.
2. Data Binding
For DDIC-based forms, fields from the assigned ABAP interface are imported into the form context and then used for data binding.
In fragment-based forms, the binding happens through fields from entities of the assigned OData service. This makes it possible to work with RAP-based or other Gateway-based data models instead of DDIC structures.
👉 Learn how an OData service is structured to be used as a data source for Adobe Forms in this blog:
Adobe Form with RAP-Based OData Service
3. Reusability
DDIC-based Adobe Form (transaction SFP) is a standalone object and can be reused by multiple different form templates. However, reusing the entire data flow is often simpler in the fragment-based approach due to the underlying Gateway service.
Fragment-based Adobe Forms, however, use Gateway-based interfaces (OData services). These services can be developed independently and reused across multiple Adobe forms, making them more flexible for large-scale implementations.
🔗 Reference: Adobe Form with RAP-Based OData Service
4. Fragments
Fragments are not supported in DDIC-based Adobe Forms.
On the other hand, fragment-based forms shine in this area. You can reuse fragments such as master forms, global templates, or common layout sections (like company logo or header) across multiple forms, making maintenance easier and reducing redundancy.
To understand how fragments work in Adobe Forms, check this detailed article:
Form Templates in SAP S/4HANA
5. Configuration
DDIC-based Adobe Forms support both NACE and OPD based configuration options, giving you flexibility depending on the process setup.
Fragment-based forms, however, support only OPD-based configuration.
If you’re working with OPD configuration, refer to Step 2 and Step 3 in this helpful guide:
Customization of Form Template using Adobe LiveCycle for Production Order
6. Object Maintenance in Configuration
For DDIC-based forms, you must maintain the driver program and form name in NACE and/or assign the form template explicitly to the process configuration.
In fragment-based Adobe Forms, you only need to maintain and assign the form template—no driver program maintenance is required in most cases.
Additional Details:
-
The call to the Adobe Form generally happens internally because we rarely create custom forms directly through the Maintain Form Templates app.
-
However, if you create a custom form with a custom OData service, you will need to call it explicitly in your own driver program or API.
Check this blog for an example of calling a fragmented Adobe Form from a custom API:
Adobe Form with RAP-Based OData Service
7. XDP/XML Files
In DDIC-based Adobe Forms, you must download the layout (XDP) and binding (XSD) files separately using transaction SFP.
In fragment-based forms, both layout and binding are downloaded together in a zipped file directly from the Maintain Form Templates app.
Explanation:
-
The XDP file contains the layout and allows a PDF to be converted to XML and back without losing information.
-
The XSD file defines the schema for how XML data should be structured when extracted from the form.
This approach makes form handling simpler and better aligned with key user extensibility.
8. Transport Management
In DDIC-based Adobe Forms, the form can be saved in a custom package and automatically captured in a Transport Request (TR).
For fragment-based forms, TR management needs to be handled explicitly, since any form created in Maintain Form Templates is stored in a local package by default.
Steps to assign a fragment-based Adobe Form to a Transport Request:
-
Create a package and assign it to the form.
-
Register the package to a TR using the Fiori app ‘Configure Software Packages’.
-
By default, content and master forms are stored under the local package TEST_YY_KEY_USER_LOCAL. Use the Fiori app ‘Register Extensions for Transport’ to assign these extensions to your transportable package.
Summary
Both approaches have their own strengths:
-
Use DDIC-based Adobe Forms when you need deeper backend control, custom ABAP logic, or NACE integration.
-
Use Fragment-based Adobe Forms when you prefer reusability, modern Fiori maintenance, and simplified OPD configuration.
Your choice should align with your project setup, extensibility needs, and whether your organization prioritizes backend flexibility or frontend manageability.
