Introduction

The Adobe form with fragments are part of the New Output Management for S/4 HANA Systems. In this blog post, I will explain, step by step, how to create a copy of this standard form with Fragments. Next, I will briefly compare the use of this form against the “standalone form” by giving advantages of its use.

Prerequisite

You must have Adobe live Cycle Designer installed on your PC.

What is the utility of services in the forms with fragments?

The ODATA service is a data provider. It gets data from the backend it generates an XML file.

What is the use of callback class?

It is responsible for calling the ODATA service to get the data, in XML format. This data will be used in the call to the form interface to print it.

Comparison between the process of calling an Adobe Form with context (the standalone form) and Adobe form with fragments.

For the Adobe forms with context, the operation is simple. To print the form, we retrieve the data in a program and using this data, we call the function module of the form to print it.

But, for the Adobe form with fragments, in a callback class, we call an ODATA service to get the XML file that will be sent to the form to print it using the concept of binding available at Adobe layer (the XDP file of the form).

What is the advantage of adobe forms with fragments?

Reuse of the ODATA service: the ODATA service created in this form is a shared and reusable resource (whether in other forms or other programs). Whereas, the other types of forms are completely isolated and autonomous.

Speed and ease of development and maintenance: It is faster and easier to use ODATA services or methods, than to copy or recreate the contents of a new one.

Reusability of fragments: this type of form is based on fragments (.XDP file). These files can be reusable in several forms as indicated in this blog post.

Step by step to create an adobe form with fragment in copy of the standard form.

In this scenario, we will take the purchase order as an example.

Copy the standard form and OData :

Create a ZSF_MM_PURCHASE_ORDER form as a copy of the standard (interface + form) MM_PUR_PURCHASE_ORDER via the SFP transaction.

The standard form uses the FDP_EF_PURCHASE_ORDER_SRV service as data provider.

In order to add our own fields to the service, we need to create a custom service.

2. Create an empty project “ZFDP_PURCHASE_ORDER_AB” using the transaction SEGW.

3. Use a data model by reference to create the entities types.

In this custom service, the reference is the standard service “FDP_EF_PURCHASE_ORDER_SRV”.

Select All the entity in the popup to get all the entity in the standard service imported to the custom service.

Save the service in the transport order.

4. Generate the OData service.

Copy the “Technical service name”, in our example it is “ZFDP_PURCHASE_ORDER_AB_SRV”. We will use it when adding it to the services catalog.

The service is generated successfully.

5. Enable the service Z in /IWFND/MAINT_SERVICE (service catalog).

Click the Add Service button.

Enter the service name “ZFDP_ PURCHASE_ORDER_AB_SRV” copied in “step4” and the system alias “LOCAL” and Click in “get services” button.

By clicking on the Technical Service Name, the corresponding service will be displayed in the final output.

Select the service and click on the “Add selected service” button.

The service is successfully added in the caltalog.

Copy the standard callback class:

Find the callback class of the standard form.

In our case we will create a callback class as a copy of the standard.

In order to get the standard callback class, we must follow the following path:

SPRO -> SAP Reference IMG -> Cross Application Components -> Output Control.

Double-click on PURCHASE_ORDER.

The “CL_MM_PUR_PO_OUTPUT_CALLBACK“ is a callback class that invokes the ODATA service.

2. Copy the standard callback class “CL_MM_PUR_PO_OUTPUT_CALLBACK” to a Z class “ZCL_MM_PUR_PO_OUTPUT_CALLBACK” using the transaction se24.

3. Update the “GET_PDF_PARAMETER” method in the Z callback class “ZCL_MM_PUR_PO_OUTPUT_CALLBACK”.

In line “12”, the standard service name is assigned.

4. Change the standard service assigned in line 12 by the service we already created in Z (in our example “ZFDP_ PURCHASE_ORDER_AB_SRV”).

5. After activating the custom class, assign the Z class created in SPRO instead of the standard callback class.

6. Next, configure the Z form created at the beginning by the new service.

Add custom fields in our service:

1. Create a custom entity “Header” to get the email to display it in the first part of the purchase order.

2. Add the “Entity Type Name” and Check the option “create Related Entity Set”.

3. Add the “Email” property to the created entity.

NB: The field “Name “will be user in the form and the “ABAP Field Name” in our ODATA service.

4. Save the project.

5. Generate the project, in order to generate the runtime artifacts of the “Header” entity.

we must, now, add the association between the entity created and the entity of the main ODATA service, so it can be called automatically.

Adding this association (Cardinality), will decide the use of the “GET_ENTITY” method or “GET_ENTITYSET”.

6. Create an association for the new entity.

Add the association name, primary entity, dependent entity, and cardinality.

The association and the association Set are created.

7. Generating the project, will automatically generate the models of the new entity created in the “MPC” class (the properties, the entity sets and the associations).

8. Add the method to get the data (in our example we will retrieve the Email) in the “DPC_EXT” class.

9. Implement the code to get the “email” ( the field “ad_smtpadr”).

Our new entity and its method are created, now we have to call the new method.

NB: In a standard service, the call of methods is done at “/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITY” method, as indicated in the screenshot below.

10. Redefine the “/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITY” method in our custom project, so we can add the call to the new method created (Header_get_entity).