Understanding Fragments based Adobe form building using LiveCycle version 10+ with OData as back-end.
Adobe has come up with new Fragments based approach for building Adobe Forms using LiveCycle designer from version 10 and above. And these Forms are part of New Output Management for S/4 HANA Systems. In this blog post I would like to explain briefly about Fragments based Forms and also would cover regular Forms (which is categorized as of type “Standalone Form”) with OData as backend. I would like to say that even though traditional Form building provisions precisely speaking SAP Scripts, SMARTFORMS and Adobe Forms with ABAP based Interfaces are still available as an alternative for this but still I would like to ask all of you to give this a try at least for learning purposes if your client is not insisting on this. If not now definitely going ahead, we might be bound to use this option (Adobe Form with OData backend) only.
To know more in detail about Adobe LiveCycle designer’s Fragments based form building you may go through the below reference from Adobe’s site: (It’s not mandatory to go through this as I would be covering the basics of that over this blog post. But for those who want to deep dive, go ahead)
Firstly, I would like to give the references of below very useful SAP Blogs regarding this.
And as highlighted in one of the blogs above I would like to give below SAP Notes references as well. Again, it’s not mandatory to go through them in order to continue ahead with this blog post, but for those who want to get into detail they can definitely go through them.
SAP Note 2228611 – Output Management in S/4 HANA
SAP Note 2292571 – SAP S/4 HANA output control -technical setup
SAP Note 2292539 – SAP S/4 HANA output control -configuration
SAP Note 2292646 – SAP S/4 HANA output control -form templates with fragments
SAP Note 2292681 – SAP S/4 HANA output control –master form templates
SAP Note 2294198 – SAP S/4 HANA output control -customized forms
SAP Note 2367080 – SAP S/4 HANA output control -customized master forms
Before going to start with Fragments based Form building I would like to go through basics of our traditional regular AdobeForms which is also referred or rather say categorized as “Standalone Forms” in S/4 HANA systems.
Basics of regular AdobeForms/Standalone Forms.
Those who have already worked on Adobe Forms before would be aware of how the initial page of Layout looks like when you open the Layout editor from SFP transaction’s Layout option.
You would see mainly there are two Objects by default:
- A Page Set called (Master Pages)
- A default Subform/Page. Let’s name it as “Content_Subform” considering below example case.
Now the concept of Master Pages is to define the Static contents/properties related to Form Layout. Such as Logo, Header/Footer, Page orientation etc. which would be common for all the pages where we would be displaying the Layout specific contents. Inside a Master Page there would be also a space reserved called Content Area ( in our case we have named it as “Content_area1”) and in this area of a Master Page only the contents of all other remaining Subform Objects(“Content_Subform” in our example case) would be displayed.
Above picture shows a Master Page named “Page1” and you can see in the Layout I have created a Subform inside “Page1” inside this Subform we can place static contents like Logo, a static Header text etc. Below that you can see a Content Area (colored with violet outline) named “Content_area1”, now this is the area where content of all the remaining( non-Master Page) Subforms/Pages (e.g. Content_Subform in this case) would be displayed.
So, the Content of “Content_Subform” would be superimposed inside the Content Area of referred Master Page.
When you click on a non-Master Page say “Content_Subform” in our example it opens the Design View in the Layout editor, see below.
While designing inside Design View you can explicitly specify which Master Page to be used in case you have more than one Master Pages defined. Here we have only one i.e. “Page1”.
Summary: So now you got to understand that in an Adobe Form Layout there are mainly two things one is Master Pages and other is the Content Pages/Subforms.
Master Pages are used to define static contents of a Layout like Logo, fixed Texts, orientation etc. And it has got a Content Area where the Content Pages/Subforms would be superimposed.
Content Pages/Subforms are the places where we would be doing the designing of contents like EKKO, EKPO, EKET details say if we are designing a PO Output Layout.
What is Fragment based Adobe forms.
Now the concept of this new Fragment-based Form designing in Adobe LiveCycle Designer version 10 and above is nothing but the introduction of reusable Master Form Layouts which would be having a collection of Fragments and Fragments are indeed collection of many Master Pages. The same Master Pages which we discussed in previous section. And these reusable Master Form Adobe layouts could be referred inside a Content Form Layout. Such that inside these Content Form Layouts, Master Pages present inside a Master Form Layout could be utilized. This covers the concept of Master Form Layout Template.
Now Content Form Layouts are the Form Layouts where we would be actually displaying the Context or say Content for example PO Layout. And inside the Content Form Layout we can refer the above Master Form Layout for inheriting the Master Pages present in it to the Content Form Layout.
Now apart from this we have the Old regular Adobe Form also which is called Standalone Form as per S/4 HANA naming conventions. So, it’s very clear that Standalone Form is nothing but a Form layout which would be independent and hence there would be no reference of any Master Form Layout for inheriting Master Pages in fact we would be utilizing the Local Master Pages defined in the Master Page set. (This we already covered before this topic)
So, in the nutshell as part of new Output Management in S/4 HANA systems (OData backed), we have below three Form Types:
- Master Form Layout. (Would be having Fragments.)
- Content Form Layout. (Utilizes a Master Form to inherit Master Pages present inside the Fragments of a Master Form Layout)
- Standalone Form Layout. (Would be having its own set of local Master Pages just as regular Adobe forms)
Creating a Master Form, Content Form and Standalone Form.
First let me show you how a Fragments based Form looks like in SFP Transaction.
What I observed the above two options (Gateway Service and Fragment Usage) you won’t get while trying to create a fresh Form using SFP Transaction. Even though we have an option for providing XML based Interface option.
So the best option is search for a suitable Form template from the Standard ( “Maintain Form Template” Fiori app) which almost matches with our requirement and copy the same to a Zversion and make your changes.
So I copied Standard Form “MM_PUR_PURCHASE_ORDER” to a Zversion and Customized it. Please note Form “MM_PUR_PURCHASE_ORDER” is a Form of Form Type “Content” so it’s a Content Form inside which we would be having a Master Form Template referenced for inheriting Master Pages.( I hope you are getting the whole sequences. )
Now the value set in “Fragment Usage” field in SFP transaction determines whether a Form is a Master Form or a Content Form or a Standalone Form.
If you select “Form with fragment” then it’s a Content Form.
If you select “Fragment” then it’s a Master Form which would be having Fragments inside it.
If you select “Form without fragment” then it’s a Standalone Form.
As simple as that.
Content Forms: MM_PUR_PURCHASE_ORDER, MM_PUR_RFQ_EXTERNAL, MM_PUR_SCHD_AGRMT etc.
Master Forms: APOC_DEMO_FORM_MASTER_AU, etc.
Standalone Forms: EDO_AR_PRINT
Master Form Explained with an example:
Let’s take example of “APOC_DEMO_FORM_MASTER_AU” only.
If you go through the above link you would observe that SAP recommends to edit a Form Layout by opening the corresponding “.xdp” file in Adobe Live Cycle designer explicitly i.e. not from SFP and then edit and once the edit is done you can upload the changes done to the Layout by uploading this edited “.xdp” file to the corresponding Form using SFP transaction’s “Upload Layout” option.
So first copy this standard Master Form template “APOC_DEMO_FORM_MASTER_AU” into a Zversion using SFP Transaction and later download the “.xdp” file either using SFP tcode itself or using the “Form Template Maintenance” Fiori app.
Now open this “.xdp” say ZDEMO_FORM_MASTER_AU.xdp using Adobe Live Cycle designer.
You can see the below components
You can see in the above Master Form we have five Fragments defined and each would be having its own sets of Mater Pages. You can make changes into these and these could be reused into many Content Forms by referring it there.
Content Form explained with an Example:
Let’s take example of “MM_PUR_PURCHASE_ORDER” only.
Just like we did before, copy this standard Content Form into a Zversion using SFP Transaction and later download the “.xdp” file either using SFP tcode itself or using the “Form Template Maintenance” Fiori app. Here there is a difference, whenever you download a Content Form system will also prompt(even though it’s optional) you to download corresponding Master Form Layout.
Remember while downloading the Master Form Layout corresponding to a Content Form, always download the Master Form which you have attached to Content Form Layout in SPRO Configuration. This SPRO Configuration I would be explaining later in this section. NOTE, Master Form for a Content Form would be picked in runtime using this SPRO Configuration only so its very necessary you download the right one when you want to edit it using Adobe Live Cycle designer.
Now open the “.xdp” file of Content Form say ZMM_PUR_PURCHASE_ORDER.xdp using Adobe Live Cycle designer.
You can see the below components,
Now once you have selected (as shown above) which Fragment of the Master Form needs to be used in this Content Form you can use the Master Pages of Fragments in the Design View.
Hope this clears “How a Master Form is linked inside a Content Form”. This was the main reason for which I penned this blog.
Standalone Form explained:
Now Standalone Form is like a Content Form only except it would be using its own local sets of Master Pages only and hence it won’t be referring any Master Form inside it.
Note: Would like to highlight the below issue which I encountered while using Master Form Layout. SAP might come out with a proper solution for this going ahead.
Please Note this would be only the partial Output Configuration meant for defining the Master Form determination and Content Form/Standalone Form determination for a output type. BRF+ config for determining the rules for Output type picking is out of scope of this document.
SPRO> Cross-Application Components> Output Control
Now apart from this I would like to give some suggestions while tweaking the standard Odata for Form building purposes.
Let’s take the example of “FDP_EF_PURCHASE_ORDER_SRV” the one which is used in Standard Content Form MM_PUR_PURCHASE_ORDER.
- I would recommend to copy a Standard Odata to Zodata Project because by doing this writing code(s) for Custom added Entities won’t need to enhance standard DPC_EXT classes, instead we could redefine ZDPC_EXT methods. Its just like we used to copy Standard Driver Program for PO Script MEDRUCK i.e. SAPFM06P into a ZCOPY.
- While copying a Standard Odata Service Project to a ZProject use the redefining option only.
And while Generating Runtime Objects, don’t forget to press the below checkbox.
- Definitely go through the below SAP Help link for knowing how to add custom EntitySet operation, GET_ENTITY is not mentioned there but it’s like GET_ENTITYSET only.
- Suppose while binding the Internal Table you are facing issues, say for e.g. instead of showing multiple line items the output shows only 1 line then I would like to suggest drag the EntitySet which you want to Display from the “Data View” to the Form Layout. After that you can make necessary changes with the Cells.
So in the nutshell AdobeForms with Fragments would be very useful in scenarios where we have multiple Content Forms sharing similar Master Pages. You make changes in Master Pages of a Master Form Layout and it would reflect into all the Content Forms where and all its used. This reusability is what we can achieve using Fragments based AdobeForms.
By this I would like to conclude my blog post and would request all to give this new Form Output management a try. Do comment out your observations I would definitely like to help out if I could. I would definitely suggest referring the standard Content Forms like “MM_PUR_PURCHASE_ORDER” to understand the binding in case of Odata backend AdobeForm Layout.
Nice blog Sijin!
Very nice blog and glad to see the use of this latest technique in Adobe world. But I think we can use fragments based Adobe forms if we go with S/4 HANA BRF+ based output management. Please correct me if I am wrong.
Since Gateway backed AdobeForms are part of S/4 HANA’s New Output Management, I guess it won’t work with the other alternative of BRF+ for message determination which is NACE and Output Procedure based.
Also other reason for this I believe is, OData based forms are triggered by Callback classes which we define while creating a Message Type, whereas in normal NACE based configuration there is no concept of Callback classes and methods instead its the Driver program which drives the output triggering.
Master form or Content form both are Gateway backed.
Very useful blog. Thank you for taking time to draft and publish this.
Currently I'm facing one issue in my BRF+ forms .
We are trying to generate multiple copies of the form with dynamic header label in each of the copies.
The only solution we found is this blog.
This is one of the challenge as per my experience with OData based forms.
Unlike Driver program based AdobeForm or Smartform where we can pass Print Parameters for multiple copies, in case of Gateway based forms am not able to figure out how we can get this done. Checked for options in the Callback classes as well but no luck.
And another challenge is you cannot trigger these forms from ABAP buy calling any Class~Methods, FMs or Programs. So I believe the workaround which is mentioned in the blog is the only solution as of now and after all it comes from an SAP personnel.
Can you please raise an Incident with SAP as well and ask for a suggestion from them.
Hi We have created a standard layout for Purchase Order with ABAP Dictionary based Interface.
But when configured this using BRF+, Purchase Order Output is not added in PO Messages once the document is created.Is there any step missed in this?
Can we use standard layout with ABAP dictionary based interface for Standard Transaction output messages?( ex.Purchase Order) or we need to use Fragments based form?
if we use XML based interface, where to add custom structure and routines?
We are using S4 HANA 1909 Version.
Please find my comments inline,
I am not sure that whether we can configure a ABAP Dictionary based form using BRF+ or not. In one of my previous project on S4 HANA 1709 we were using ABAP Dictionary based forms but we got them configured using NACE.
This really depends upon which Output Technique you are opting for. Whether its SAP Script, Smartfomrs, Adobe Forms normal or Adobe Forms with Odata.
I could see for Scripts MEDRUCK is there, so for MEDRUCK SAP has also provided Standard Driver program i.e. SAPFM06P. Likewise for Standard PO Adobeforms(with OData) we have Form MM_PUR_PURCHASE_ORDER and the corresponding Gateway service FDP_EF_PURCHASE_ORDER_SRV. Now this you cannot mix with each other i.e. Driver Program for MEDRUCK with AdobeForm MM_PUR_PURCHASE_ORDER, reason is quite simple they are not meant to be used together.
I would like to suggest you to get MM_PUR_PURCHASE_ORDER and the corresponding Gateway service FDP_EF_PURCHASE_ORDER_SRV configured as Output by Functional and give this new Output Technique a try. Else you want to stick with ABAP based Interface then please create it from Scratch.
With XML based interface you mean't Odata based Adobe forms then you need to Redefine the Standard Gateway services. I have explained the same in the end of blog. Please refer.
Thanks for your detailed reply.Very Useful Info.
We can not use NACE,as Purchase order BRF has already been activated in system and one other output already configured using BRF with Odata and XML based intf.
I have the following scenarios so exploring on how to configure below combinations( or these combinations wrong?)
1.Interface is ABAP Dictionary, Form is Standard layout with no-Framgments/No Odata–.> ??
2.Interface is ABAP dictionary, Form is Standard layout with Fragments without Odata–>??( Removed Odata name ).But the problem here is the strcuture from interface is not showing in data view of layout event though its added in Context.
form without odata
3.Interface is ABAP dictionary , Form is Standard layout with Fragments with Odata–>This is ok when we followed standard config steps.
Thank you so Much
If you are going with BRF then I would suggest to go with ADOBEForms with OData as backend.
For creating the same you have to copy Standard Form 'MM_PUR_PURCHASE_ORDER', we cannot create it directly using SFP.
Please see the below portion of blog which explains this limitation:
And Copy the Standard Gateway Service using Redefine option and add custom Structures as per your requirement.
And finally replace the Gateway Service in the SFP transaction with your Custom developed one.
Thank you Sijin Chandran for your detail explanation.It Really helps to understand the concept.
I will try form with Odata .
Try configuring the Standard First with the help of Functional.
And then you can start building your own Custom one.
I have create a Custom Odata ServiceProject in SEGW and trying to Extend the DPC_EXT class: ZCL_ZFDP_PO_OP_DPC_EXT to get the PO header Custom Fields(Z Fields),PO item Zfields into my new structures: EKKO & zekpo .
1.My Entity Set name is EKKO,ZEKPO and selected the required Zfields into the Properties .But how to get the ekko-zfields values into EKKO during PO Creation in method ZCL_ZFDP_PO_OP_DPC_EXT~EKKO_GET_ENTITY?
2.Do i need to assign this Custom Odata service project to services in /IWFND/MAINT_SERVICE ?
I suppose the above is a custom method created by you using which you want to get your custom Entity/EntitySet get filled.
If yes then you need to code inside this method. And also you would need to redefine below Standard Methods,
The first method in case you are coding for Entity ( i.e. single records fetch)
The second method in case you are coding for EntitySet ( i.e. Multiple records fetch).
Please go through below link for more details( I have already given the reference of this link in the blog as well).
I would request you to go through the blog again.
For Second point, yes you would need to maintain it using /IWFND/MAINT_SERVICE, in all systems.
Just to let you know that we can configure and use the ABAP Dictionary based Adobe Forms in BRF+ based output management.
Thanks and regards,
Thank you for the blog, it is very useful and interesting.
If we want to add more information to the standard output form do we really need to copy the standard service, for example : "FDP_EV_CENTRAL_CONTRACT" ?
Or could we just create a custom one from multiple CDS views that has all the necessary fields and add this new service to our Z* copy of the form MM_PUR_PURCHASE_CONTRACT ? ( Of course also the SPRO configuration would need to be changed accordingly in which we use our own Z* Callback class to call the new service )
Please find my response inline,
It's recommended to copy( actually the concept is called 'Redefining' the Gateway service) reason being the Standard Gateway Service is Modeled in such a way that it works perfectly for the purpose of Output Messaging. It's designed in such a way that it can be clubbed well with the Callback classes.
For eg. see below Model Hierarchy of FDP_EF_PURCHASE_ORDER.
It's a QueryNode Entity which is on Top and the remaining Application related Entities are subsequent to that. That's how it's designed. And remember our Callback classes hits QueryNode first.
So its recommended to Redefine the Standard Gateway Service into a Z GW Project and add all the required Custom Entities and Associate them accordingly.
Here I would like to highlight one thing it's not necessary to create a Z Callback Class always. Actually it's the Method IF_APOC_COMMON_API~GET_FDP_PARAMETER of a Callback class for which we need to create a Z or Enhance it.
See for example in case of PO Callback class CL_MM_PUR_PO_OUTPUT_CALLBACK.
This is the Method which passes Parameters to QueryNode, you can see earlier the Gateway Service was hardcoded there, but with latest Update SAP has commented the same. Hence this will work for all the Services now, that means even if you attach a Z Gateway it will Work.
But in case of CL_MM_PUR_RFQ_OUTPUT_CALLBACK which is for RFQ still the Hardcoding is there so instead of creating a Z Callback I simply Enhanced it, so that our custom Gateway gets called properly with Parameters passed.
I hope I was able to answer your query.
Thank you very much for explaining, it all makes sense now!
Good one Sijin.Appreciate your effort
Very helpful blog Sijin Chandran.
I have one question regarding the debugging of Adobe Forms based on the new architecture. There was 2 part where we used to do our custom code for Adobe Forms based on the earlier ABAP Interface, one was the Driver Program another was the Code Initialization in the SFP Interface. But now we do everything related to ABAP in the SEGW _DPC_EXT class and can do some Scripting inside the ALD.
Now my situation is that everything is fine till the Gateway where the data is populating correctly in my related node, but I can't see it appearing in the Form. So if I wanted to see if the data is flowing correctly to the form or not, where I need to debug and how?
Please find my comment in-line,
- For debugging at Form side , I don't have any clue right now since we don't have any Code Initialization section as we used to have with ABAP Interface based AdobeForms. Please check whether your mapping is correct or not. Try to map and check an Entity( only 1 record ) first and then check with EntitySet( n records ) mapping.
That is a very interesting blog. Thank you.
One question remain. How those customized contents and masters forms are transported through the transport layer and moved from the development to the QA and finally to the production environment?
All the Odata information are stored in a transport where the current STMS handle it.
But the transport doesn't contains the forms layout.
AdobeForms are still maintained as a SFP Object only. For eg. Standard Content Form MM_PUR_PURCHASE_ORDER this you can open and see using SFP Tcode as a SFP Object only. Likewise when you create a ZFORM it will ask for a TR.
I finally found the solution. It will be done in few steps.
This will assign the forms to the selected package and create a new transport that will be handled through the regular STMS.
Thanks a lot for you post. I'm new with Adobe Forms and I need to customize a standard XML Based Adobe Form (for Billing Documents), i know i need to copy the standard form and make the required changes, but i have the question, is it posible to change in the OPD configuration (for Billing docs) the standard xml based form to one custom abap dictionary form ? That because i have found information about how to custom ABAP Dictionary Forms (with Context) but not about how to custom XML based forms. So i have two options
Thanks a lot.
but i have the question, is it posible to change in the OPD configuration...
By stating this I guess you want to use ABAP dictionary based AdobeForms and want to make use of BRF+ only as Output Determination. If my assumption is right, then you can see in one of the previous replies @Prabhjot Bhatia has mentioned that it is possible.
And one more thing Customising the XML based OData Adobeform should be easy only and the above blog should help you on that, only difference here is above example is for PO and for you its SO. Give this a try because going ahead this would be the widely accepted FORM technology I believe.
Very well explained. I have few doubts can you please guide me here:
I have a requirement:
1. Change the Logo & footer
2. Add additional details in the content part: partner addresses & line item details.
3. Add additional fields which are not in the PurchaseOrderNode entity.
As per my understanding, we need to do the below:
1- Create a custom ODATA Project( Copy of standard) - is there any other option?
2- Add a new entity for required missing fields.
2- Redefine the methods
3- Create a custom form using Maintain Form template
4- Add missing fields in the form
5- Create a callback class (copied from standard) and add custom service we created
6.- Configure Form & callback class in BRF+
7. In case the logo or footer needs any change, create a copy of the master template.
All the points mentioned by you are correct.
It's not necessary for Callback classes to be created, even the standard would work in many cases. I have mentioned about this in one of the earlier comments. Please have a look on that.
For Logo you can use Image Field with Embed functionality and Create a Master Page fragment and reuse it for many other Content Forms. So the benefit would be in case of Logo Change just change it in the Master Page Fragment and all the Content Forms where and all this Master Page Fragment would be used, the change will reflect.
Thanks for the explanation. I have a requirement to change the configured standard form (SRF_PH_WHT_FORM) with a custom (ZZ1_SRF_PH_WHT_FORM) one to change some texts
in SFP, the standard form i copied is Form without fragment, meaning it is a standalone
I downloaded the form and modified it in the designer (changing some texts and resizing some boxes) kindly see below
then uploaded back the customized form using fiori:
Lastly, i changed the config in the form template to use the customized form
but when i regenerated the form in fiori, the customizations did not reflect
Do i still need to do some configurations in BRF+ even if the form is not Fragment-based?
Very nice blog. I foloowed exactly same approche, by triying to add logo ( New entity ):
-Add new entity while redefining Odata service "FDP_EF_PURCHASE_ORDER_SRV":
-Implement the GetEntity related to the new added entity, and even the dispatecher method
==> For Odata Part I think that's all what we need ?
-In the app " Maintain Form templates" , I copied the Standard Form to Z one and I did the following :
- I used this master form :
- I Download The form ( With Master form included ) .
- Import xdp file to Adobe live cycle, but I don't find the created entity when I want to do the binding :
Please tell me If I am missing something ? And Methods Get_Enity not triggred with ME9FF to generate output.
check whether the Output Configurations are in place properly.
Keep breakpoint in CallBack class as well.
I appreciate your detailed technology responses and hope you are still monitoring this thread. I would like to ask something more "business" foundational. My development team is pushing back on using Adobe Fragmented Forms as a technology complaining that they find them too complex nd that they can more efficiently code changes using the older technologies (so for example, proposing to clone and enhance SD_INVOICE_FORM01 rather than clone and leverage SDBIL_CI_STANDARD_US). Is there a compelling business reason to use Fragmented Forms as a technology? Is there any downside to using the older technology (perhaps with respect to support of S4HANA standard enhancement techniques, CDS views and ODATA services, or with respect to Fiori and web access)? What I am trying to determine is whether the issue is training and possibly reluctance to change or if there are bona fide usability issues? If we give-in and stay with the older form technologies, is there a downside we should consider?
Rather than stressing on the 'Fragmented FORM' factor consider this as a FORM building provision using OData as a back-end instead of traditional ABAP Driver-program based back-end. And this is where it has got an edge over the older technologies. Now since the push is on cloud based solutions, hence the Database access on these Cloud based products ideally should be made using API(Application Process Interfaces) only and these Odata Services are the APIs. So this Odata based Forms are nothing but Forms which can leverage APIs, of course the APIs should be designed in such a way that it could be consumed from FORMs.
So, I guess this is the reason SAP is pushing on this and hence we should consider this, even if you see the DEMO forms also they are having a Good collection catering to majority of scenarios, that itself says a lot.
But having said that there could be many cases where we still need to stick with older ABAP program based AdobeForms, so for those scenarios choose wisely.
Fragment concept is just for reusing a FORM with multiple other FORMS(as already mentioned in the blog).
And finally if anyone puts dedicated efforts these are not that difficult to grasp actually, our old FORM technologies(especially when SMARTFORMS were introduced when already SAP Scripts were there) would also have faced such a situation once but now you see how established they are
Hope this answers all your queries.
It’s really helpful blog..Thanks for sharing!!