Introduction
I have been working on a few projects where I have used the new Adobe Forms tool from within the ABAP side of the WebAS 640 (Transaction SFP). These projects use the Adobe tool to create printed forms not interactive ones. Basically I have a BSP application that I need to produce a nicely formatted printed version for. Although my first form took about a day to design because I was still learning the tool; my latest one only took about 45 minutes total (that includes writing the print program, the form interface, context mapping and of course the form design). I would like to share these experiences, specifically focusing on the techniques that once learned made it possible to go from 1 day to 45 minutes of build time.
We will start by looking at the BSP application that I am trying to represent in the Adobe Forms Tool.
!https://weblogs.sdn.sap.com/weblogs/images/1918/AdobeBSP1.jpg|height=346|alt=image|width=511|src=htt...!
!https://weblogs.sdn.sap.com/weblogs/images/1918/AdobeBSP2.jpg|height=389|alt=image|width=513|src=htt...!
As you can see from the screen shots, I have scrollable areas and tab strips in my application. These are great UI components for the interactive experience, but don't make for very good print outs from the browser. This was the reason that drove me to offer a print option via one of SAP's forms technologies.
Long Text Area
The first place where I thought I was going to have a problem was with my Long Text Description. Back in R/3 this is Document Information Record Long text stored like most long - in multiple records with fixed length (132 characters in this case). For my BSP application I had already concatenated all these text lines into single string for passing to the textView element. I originally thought that I would have to go back to the separate record format. This is what I have done in the past with SapScript. As it turns out I can just pass the entire string through to the Adobe Form. It will pick the Carriage Return/Line Feeds that I inserted into the string for proper display in the BSP page. All I had to do is set the following parameters on the field in the designer.
Tables
It is fairly common to have tabular data within SAP form output. Although I really like the Adobe forms designer tool, the creation of tables is one area where I though the process was cumbersome. I nice table designer like we have in SmartForms would be appreciated. Once I had done a few tables however I found that the process wasn't too bad. There certainly are more and better visual formatting options for tables within the Adobe tool.
I had sent my internal table through the Form interface and added it via drag and drop to the Context. I could see the table, and its components in the data view of the forms designer.
You start the table creation process by dragging a subform object from the Library palette/Standard tab. This first subform represents your entire table, so place it where you want your table to be. Also resize it large enough to easily insert additional elements inside the subform area.
Next you need to insert two more subforms. One will become your header and one will become your table body.
Now you can insert the individual fields that will make up your Table header and body elements. You can insert static text, text fields or any of the other standard form elements. Drag and drop the fields from your internal table represented in the Data View to bind to the data from your context. The size that you make the individual elements doesn't really mater at this point nor does your exact alignment. You can see that they are quite a mess in my designer at this point. They will be resized in a few steps. Notice that you have to type static headers. I never found an easy way to bring in field titles. You can see from my screen shot earlier that the language dependent field descriptions map through the interface and into the content. You can see them in the data view under Descriptive info. It sure would be nice if these automatically mapped to the table headers or to text fields that are bound to context items.
Finally we are ready to turn this mess into a table. We return to our highest level subitem that represents the table itself. We need to go to the Object palette, Subform tab. The default Subform type is Position Content. We need to change this to Flow Content. Now a new option opens up that allows us to choose the Flow Direction. For this element we choose table. Now we reach the point where we will define our column sizes. A new field has appeared where we must list all the column widths separated by commas. We had two columns that we will make 4 inches each.
The process is now repeated for the subform that represents our table header and our table row.
The layout in the designer now looks much nicer.
What we have so far will give us a nice looking table with exactly one row. We must go into the subform that represents our table row and in the Object Palette/Binding tab make the proper setting so that the row will repeat for each item in the internal table that is bound from the context. To do this we set the Repeat Subform for Each Data Item option. If you want to get fancy you can even set an overflow leader so that the table header is repeated if the table must span more than one page.
There are two types of Graphic Nodes within Adobe Forms Context - Graphical Context and Graphical Reference. With Graphical Reference, you only have to supply a URL where the image content can be read from. I had originally started to use this option and just pass the URL to the icons. However there appears to be a bug in my WebAS 640 SP12 system that produces a short dump for this type of graphic node if it is placed in a table node (Updated 7/18/2005: This problem is now fixed via OSS note 862915). This left me with only the Graphic Context Option. I therefore just supply the fields of my table that contain the content and the mime type. Also note that there is a bug in SFP in 640 SP12 that causes the Graphic Context not to syntax check if the mime type is supplied via a content attribute instead of static string. This problem is also solved via OSS note 862431.
The graphic node now appears within your data view in the forms design and can be dragged onto the form and placed within a table row subform. I did find one problem however. When it drug this node element over to my form, it didn't generate a image field. By default it created a text field. I had to manually change it to an image field.
!https://weblogs.sdn.sap.com/weblogs/images/1918/AdobeGraphicDataView.jpg|height=247|alt=image|width=...! !https://weblogs.sdn.sap.com/weblogs/images/1918/AdobeGraphicImageField.jpg|height=178|alt=image|widt...!
Form Paging
When I first printed my form everything looked good, until I found an example that should have wrapped around to a second page. Instead the content ran right off the first page and that was all I got. The Form Designer really seems to default to fixed position content. With lots of variable length table output, that just doesn't work well. I found that I needed to change some settings ont eh Main SubForm that all of my content lived within. This subform needed to be changed from Position Content to Flow Content. Since I just wanted my content to flow out like a continuous report I only have one Master Page with a single content area. However with the use of multiple Master Pages and Content Areas within them, you could have static content (such as a header area) that repeats on each page mixed with variable content (like the table items). The following were the settings that I came up with that best fit my needs on the Main SubForm.
Form Output
In the end I was quite happy with the results of integrated my Adobe Document in with my BSP application. Because the resulting document is printed from the Server, I just created a small printer dialog much like the one in the SAPGui for producing the form output.
Also because I had used the Adobe tool, the default format is PDF. Therefore I don't have to do any conversion if I want to offer the content as a downloadable PDF file as well. There is a flag in the output parameters structure of the open Job function module (FP_JOB_OPEN) called getpdf. If you mark this flag, the binary content of the document will be returned to your application in the formoutput return structure. This single binary string is all ready your document in the PDF format. No further manipulation is necessary.
In case anyone is interested this is what the finished document ended up looking like in PDF, I have included some screen shots. I have marked over the top of some sensitive information. I should also note that capturing the form as an image and shrinking it did lose some of the detail of the lines and shadows around the tables and table headers.
!https://weblogs.sdn.sap.com/weblogs/images/1918/AdobeOutput1.jpg|height=340|alt=image|width=472|src=...!
!https://weblogs.sdn.sap.com/weblogs/images/1918/AdobeOutput2.jpg|height=279|alt=image|width=473|src=...!
57 Comments