A question by Mr. Jean-Pierre Loquet attracted my attention. He asks about Printing remote PDF. The problem is like this: There is a PDF template (of course the template must have appropriate format or you won´t be able to use it in the following scenario) on an external non-SAP server/ webpage. The programmer wants to use this template the same way he would use a form template saved in the SAP system (transaction SFP, integrated LCD in your SAP GUI etc.).

I feel it could be difficult to figure out what are all the important parts of the puzzle and how to glue it up together, so I blog about it. It could also help people whose scenarios are slightly different but they could use a part of the process I am going to describe.

So, let me describe me idea about how to implement the scenario

The basic idea/ where to start from

• The idea is based on the demo report provided by SAP, it is called FP_PDF_TEST_19. This report lets the user to read a form template from the hard-drive, read the XML data file from the hard-drive and merge it together using your ADS service (note: you need to have the ADS service installed and configured, so make sure you have it before starting to implement this).
• Now we can split the problem into three parts: how to get the XML data, how to get the template, how to merge it together. The third part is obviously solved by the source code of the mentioned report, so that is not a problem and I will only discuss the first two parts.

How to get the XML data

There are multiple ways how to do this, I believe. First: you need to understand what data you need to use. For this purpose the ADS trace fits the best. Go to SFP, options, set the trace to very detailed trace and print some form of yours. In the attachments section you get the set of the debugging files, which you can use for various debugging (like to check if the data are coming from the backend, if there are any problems with javascripts within the template etc.). And one of the files is a XML file with data coming through the interface from the SAP system. Use the file to understand how you should shape the XML file you will merge into the template.

For those who are not aware of it, you can generate the testing XML file from the LCD as well. Go to: File - Form properties - Preview - Data file and have the file generated by the LCD. This probably fits the best the process where the template comes from an external SAP source (but still had to be designed in LCD).

Now you know, how you need to shape the XML. (To be precise: you cannot use any SAP tools for this since you don´t have the DDIC structures and an interface for the external form, right? But you could create the structures and use it in an interface, which will not be implemented by any SAP form template. Or you could change the process flow of the forms: create a template in the SAP system (with the interface etc.) and using some job you will export the template so the forms are available on the external "site/server" like it was needed in the original scenario. Then you would be able to simplify things: you could use the ordinary forms printing instead of this complicated one. But that is another story).

Let´s create the XML file now. There are ways how to do it. You can create a simple transformation, write the XML envelope as a static text into a body of the transformation and dynamically fill the variables into the specified place. If you´re interested in the transformations, there are plenty of course where to read about "ABAP simple transformation". Or you can create a DDIC structure corresponding with the structure of the XML file and use transformation ID to do the most of the work for you. I hope you have the file now.

How to get the file

In the report mentioned above you can read how would you read the file if it would be saved on your desktop. You need to change the process so it can be done by the server without the user interventions. There are several ways how to do it and I will let you search for the details. An important question is when the server will download the template from the external source. Every time a form is printed from SAP? Or a synchronization tool should be created for this purpose? It is up to you and the process.

Alternatives and non-ABAP tools

If you don´t like this way, I am sure there are alternatives, but I am not aware of any alternative in ABAP. If you can use Java and can do some Java, you can use iText library to manipulate the PDF file. You would read the template into Java, set the fields one by one, and save the new file filled with data. But you mostly don´t have the option to run external Java (ok, you could do it from the Portal for example, but could be an issue from ABAP).

By the way, sometimes it is very useful if you can use the external tools, for example when you Converting multiple files in a PDF-spool-job into one sinlge PDF (what is not possible with the current version of Ads, I believe, correct me if I am wrong, because it would help hundreds of people, check for yourself how many times this question was asked in the forums).

Hope these lines will spare somebody some time. Please comment, I am ready to improve the text with any ideas you might have. Regards Otto

First of all I would like to warn you that quite many SAP standard forms are a little crazy. No guidelines and best practices for the Adobe forms development were followed and thus it is a little troublesome to use or even change some of the forms (of course only few are not that good in my opinion and of course I didn´t have the "pleasure" to check all the available forms). Because of that it is important to decide if you can accomplish your task with the standard form (with some LITTLE enhancements) or if it would be better to start from scratch.

Which part of the form printing scenario to reuse

If the standard form suits your needs and you only need to realign the layout a little, translate the texts, add a logo, add a note for the user or add a field or two, definitely use the SAP-standard form. I would recommend using the standard form for the complex and difficult finance or logistics problems as well.

Even if the form is not too complex, you must always keep in my there is a printing program associated with the form which extracts and transforms the data needed for the form.

If you would use only a small part of the delivered functionality, consider starting from scratch. Well, you don´t have to recreate everything. You could reuse the printing program and create only a new form for example. In that case you will have to decide, if you will create your own form AND the new interface or create only a form (the layout) and reuse the standard interface.

You will probably reuse the interface if you will use most of the data prepared in the standard interface by the standard printing program. You will probably not use the standard interface if it is messy (some are a little messy, in my opinion), if you would use only a few fields of the big set of data (remember you can achieve a better performance if you de-activate the nodes not needed in the form layout) and especially if you can get the data you want, but not all and/ or not in the right format (for example there are the lines of some type, but half of the fields you need to use in the form is missing).

If you will reuse the interface, you need to find the very end of the printing program, where the name of the form can be changed easily (or find the customizing where you can do it the right way!), and repair the program.

If you want to change as little as possible

I will describe what steps you need to perform when you want to keep all the standard parts of the form printing scenario. You have two basic options:

• You will not change the printing program, you will change the form interface and the form layout. ABAP coding to get some new data or change the standard pre-fetched will be done in the initialization part of the form interface.
• Or you can move the changes out of the form and change the printing program as well - add a function module call into the printing program (just before the printing itself, you know all that FP_JOB_OPEN and stuff) to compute/ extract the new fields for you and change the call of the form, where the new items in the interface must be added explicitly.

Pick an option, the choice is up to you. Let´s describe the other details:

• Open your interface first: add all the new fields you cannot find in the standard interface and you need to have them in the form layout here. Now the rest of the work is split into two parts - to be done backend (change of the printing program, ABAP coding in the interface or in the printing program to get the data) and to be done in the form layout (add the fields on the form).
• Do the ABAP coding. Choose if you will place it into the initialization part of the interface (then no printing program changes are to be made) or you will repair the printing program
• Change the form layout. Add the new field from the Data View (mostly the tab can be found on the left side of the LCD). If you don´t know how to operate the designer, you can just drag&drop the field (from the data view to the form layout).

Testing the solution

Just run the enhanced form and wait for the result. If something is not going as expected, check these (in my opinion the most often made mistakes):

• Check the binding of the new fields (binding is the mechanism how to assign the fields of the layout to the variables in the backend/ form context/ form interface - well, the data you send from your ABAP program).
• Check the values coming from the backend. Sometimes unexpected values appear and the form stops working (my favorite behavior is when the problem occurs for a single business document out of the thousand, where some crazy testing value like ABC can be found in the place where the number was supposed to be).
• If there is any scripting in the form, check it. When a syntax error is reached, the script is ended, which may produce some interesting behavior. Here can help you to upgrade to the newest version of LCD (what is 8.1 at the time I write this blog, check SAP note 1176858), where the scripting support is better.

Hope that will help some people not to struggle with the standard forms and remember: use the versioning, both for the coding and for the form objects! You may think that is for loosers, but you will understand at the moment your whole-last-week-work will stop working and you will not be able to find the moment when everything went wrong, what causes the problem or how to find the solution (and implement it on time).

Regards Otto (you´re welcomed to SAP Interactive Forms by Adobe)

p.s.: Just in case you don´t know if there is a form you can use to satisfy the needs of a customer, you can check the list of the standard forms like this: Go to http://service.sap.com/erp  (SAP ERP) -> Media Library - SAP ERP Overview -> Detailed information cross ERP -> Adobe Forms for SAP ERP

Behind many questions there are people who can do some basic things in Adobe forms (because that is not their job, how many of us has worked on the projects, where there were so many forms that the project could pay a guy for the Adobe forms only...) and are frustrated these basics don´t fit to the clients' needs. Sometimes you need to/ must completely change your approach because the way you´ve chosen is very awkward to do or use, not scalable, not maintainable or doesn´t solve the whole problem ("nobody wants to say "I have succeeded with the half your task, don´t expect the second half" to his client). Sometimes it is enough to use these basics in a little different way and you don´t need any "advanced" techniques.

That leads me back to adapted proverb: "think first, think in variants, develop later". You can spare some time or your good temper:))

For example, there are questions like: " I would like to use Adobe forms in my workflow." (Why? I ask. How?) "Because my clients want me to do" (Mostly means that the client is using Adobe and wants to use it everywhere:))).

My typical answer:

Do you want the form to be a transport medium? (If you write the data into a form only to spare the backend coding for every WF step - you don´t need to save the data from every WF step, mostly the last one is enough. It also answers the question if the form is WD/ online - because you would have to maintain all the steps in the backend, WD is only a screen and doesn´t hold data itself, but the offline/ saved filled form can hold data).

Do you want the form to be send as a change notification? Or do you want to archive the WF steps result (like in GOS etc.) (You can use the WF data to print a print form and send it through email to notice somebody that a change has been made and he needs to archive the file, send to the partner/ client etc.)

Through what GUI can the user access the WF? If he can use the portal, then the WD form is an option. You can also use the "off-SAP workflow" with the offline form, which is only uploaded back to SAP through portal (or SAP GUI user which has mostly the better license type).

Do you want to use some Adobe+WF framework (like HCM P&F, ISR)? (obvils mason). Etc., etc.

Is it always better to be able to choose the approach or to let your customer choose it. You won´t get caught in the corner with something you can´t do.

Like my first morning post today:

Question: We have a requirement where we need to display the address which is fetched in to a internal table in a block in adobe interactive form.

My answer: There are options how to send the address into a form:
1) There is "business address service" (BAS: http://www.****************/Tutorials/AdobeForms/Address/WithBAS.htm).
2) There is a way how to directly send the standard texts into the form - through context text elements.
3) To format the address you can use multiple text fields arranged in the positioned subform. You can use the "standard custom" Library component Address block (tab Custom in your LCD). If you would like to use this option and doesn´t like the "standard custom" address, create your own Library component with this blog
4) You can also use the static text with floating values within (right mouse, floating field)
5) you can use the table, sure, create a subform table, subform line/ row, create a single text field to display the string line from your backend source table, do the binding
Comment: maybe the data are not extracted from DB/ prepared for the form the right way, so you can´t use some of the options. Maybe you can use the other way, which will make coding faster/ easier, helps the user maintain his data with some more comfort etc.

Hope this helps you/ inspires you to think about "thinking in variants". Have a nice day, Otto