BC480
PDF-Based Print Forms
SAP NetWeaver Date Training Center Instructors Education Website
Participant Handbook
Course Version: 2006 Q2 Course Duration: 3 Day(s) Material Number: 50080101No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Trademarks
• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.
• IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation. • ORACLE® is a registered trademark of ORACLE Corporation.
• INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.
• UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. • Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,
VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
• JAVA® is a registered trademark of Sun Microsystems, Inc.
• JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
• SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
Disclaimer
THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING
WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,
INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.
This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions
American English is the standard used in this handbook. The following typographic conventions are also used.
Type Style Description
Example text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options.
Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet).
Example text Emphasized words or phrases in body text, titles of graphics, and tables
EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.
Example text Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.
Example text Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.
<Example text> Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.
Icons in Body Text
The following icons are used in this handbook.
Icon Meaning
For more information, tips, or background Note or further explanation of previous point Exception or caution
Procedures
Indicates that the item is displayed in the instructor's presentation.
Course Overview ... vii
Course Goals ...vii
Course Objectives ...vii
Unit 1: Overview... 1
Overview: Architecture ...2
Unit 2: Interface ... 13
The Interface as the Link Between Program and Form... 14
Unit 3: Context... 35
Form Context: Using and Extending a Form Interface... 36
Unit 4: Designer ... 79
Adobe LiveCycle Designer: Overview ... 80
Adobe LiveCycle Designer: Structuring a Form ...108
Unit 5: Layout... 127
Static Form Elements...129
Dynamic Form Elements...143
Tables...171
Unit 6: Scripting in the Form ... 193
Scripting for Form Elements ...194
Unit 7: Integration into ABAP Programs ... 217
Integration of Forms into ABAP Programs...218
Unit 8: Tips and Tricks... 233
Download/Upload and Import ...234
Accessibility Aspects ...240
Unit 9: Appendix ... 249
Styles ...251
ABAP Exception Handling ...261
Customizing ...266
Basic Administration ...270
Migration ...281
In this course, you will learn about the tool “SAP Interactive Forms by Adobe” and its key capabilities. You will learn how to design forms and how to integrate them into ABAP print scenarios.
Target Audience
This course is intended for the following audiences:
• Project team members, developers and consultants who are responsible for form printing
Course Prerequisites
Required Knowledge
• Programming experience with ABAP
Recommended Knowledge
• Experience with SAPscript or Smart Forms strongly recommended, but not compulsory
Course Goals
This course will prepare you to:
• Create print forms with the tool “SAP Interactive Forms by Adobe” • Integrate forms into ABAP application programs
Course Objectives
After completing this course, you will be able to: • Use transaction SFP
• Create and model form contexts • Create and model form interfaces • Use Adobe LiveCycle Designer
• Create and design complex forms for printing with the tool “Interactive Forms”
SAP Software Component Information
The information in this course pertains to the following SAP Software Components and releases:
Unit 1
Overview
Unit Overview
This unit gives an overview of the transactions and tools involved at design time. It also provides a brief overview of the technology that is actually used at runtime.
Unit Objectives
After completing this unit, you will be able to:
• Name relevant parts of the architecture of the tool “Interactive Forms” • Name the steps to create a printing scenario with the tool “Interactive Forms”
Unit Contents
Lesson: Overview: Architecture
Lesson Overview
This lesson will show you the components of the tool “SAP Interactive Forms by Adobe” that are required for a printing scenario, and how they interact with the SAP system.
Lesson Objectives
After completing this lesson, you will be able to:
• Name relevant parts of the architecture of the tool “Interactive Forms” • Name the steps to create a printing scenario with the tool “Interactive Forms”
Business Example
A travel agency wants to print invoices for their customers' flight bookings using the tool “Interactive Forms”. In the project planning phase, an overview of the architecture and some basic technical background is required.
Parts involved in a printing scenario
How does creating a document work from the user's perspective?
• The user starts the application, for example using a transaction code. • The user enters the data required on the screen and triggers the business
process.
• Several print scenarios are possible. One is previewing the PDF document in Adobe Reader, which is automatically loaded into the SAP GUI. From here it is possible to trigger a printout so that a spool request is created, which can be administered in transaction SP01.
Figure 1: User's Perspective: Printing with PDF-Based Forms
Note: For an overview of available forms for mySAP ERP 2004, see SAP Note 735050. Please note that the forms delivered with mySAP ERP 2004 are for pilot customers only.
For an overview of limitations for the solution Interactive Forms in SAP NetWeaver 2004s, please see SAP Note 894389.
For an overview of general limitations for mySAP ERP 2005, see SAP note 852235.
Figure 2: The Tools Involved (Design Time)
Interface (transaction SE80 or SFP): The interface defines which data a program can possibly pass on to a form. It also contains global data and initialization coding that can be used in a form. Interfaces are reusable. They are Repository objects. Form template (transaction SE80 or SFP): Typically, a print form template consists of a context and the layout.
• In the context, you define which parts of the interface you actually want to use in that particular form. You can also add elements like text modules or images.
• The layout typically consists of static elements and dynamic elements (which often have equivalents in the context). The layout is defined in Adobe LiveCycle Designer. Technically, it is represented in a special XML format: XDP = XML Data Package.
Before a form template can be used, it must be activated. Activating a form template involves a context syntax check, saving the form template, and, most importantly, the generation of a function module. The generated function module encapsulates all properties of a form and is called whenever a program triggers form processing.
In some parts of the documentation, you will also find a form object instead of a form template.
At runtime, an ABAP program retrieves/calculates all necessary data and passes it on to the generated function module. As interfaces are reusable, a single program could be used for various form function modules, as long as they use the same form interface.
Figure 4: Architecture of a print scenario
A look behind the scenes:
Since SAP Web Application Server (SAP Web AS) 6.20, an SAP system can not only run ABAP programs, but also Java programs. For this purpose, a Java engine must be installed (Java 2 Enterprise Edition, or J2EE).
There are basically two scenarios how PDF based forms can be used in an SAP system:
• Integration into classical ABAP programs.
This is typically the case when mass processing of forms is required, e. g. for printing, mailing or faxing them. Data retrieval, user communication, or result processing (like spool processing) is done with the logic of ABAP screens (using SAP GUI). Technically speaking, interactive scenarios are also possible with SAP GUI integration, but you would typically have a browser-based UI for interactive scenarios.
• Integration into browser-based, interactive scenarios.
In interactive scenarios, individual forms are processed and displayed in a web browser. The user can then enter data into the form and trigger the further processing. You can use Java Web Dynpro or (starting with SAP NetWeaver 2004s) ABAP Web Dynpro.
In both cases, the form rendering is done by Adobe document services, which are part of SAP NetWeaver's J2EE engine.
A more detailed view of the ABAP print scenario:
At runtime, an ABAP application program uses the Post Processing Framework (PPF) to determine whether an output is required and, if so, which output. The Post Processing Framework provides SAP applications with a uniform interface for condition-dependent generation of actions (for example, printing delivery notes, faxing order confirmations, or triggering approval procedures). The actions are generated if specific conditions occur for an application document. They are then either processed immediately or at a later time. PPF is the successor to Output Control.
The form processing runtime provides functionalities like opening and closing a spool job for PDF-based forms. It will then call a Web service, which will communicate with Adobe document services via Simple Object Access Protocol, or SOAP (an XML standard), using the http protocol. Adobe document services are responsible for form rendering, including filling in fields, page breaks, or applying layout settings.
Adobe document services must be deployed on the J2EE engine. They consist of the Adobe document services Web service and the following SAP J2EE services: Document Services Data Manager, Document Services Font Manager, PDF Manipulation Module, XML Form Module, and Document Services License Service. These services can be installed together with SAP NetWeaver Application Server.
Adobe document services will return the PDF, which will then be processed further, depending on the settings of the ABAP program. For example, it might be sent to the spool for a printout or mailed.
In some parts of the documentation, Adobe document services might be abbreviated as ADS.
Advantages over Smart Forms/SAPscript
• PDF is a de-facto standard for forms in the Web
• Adobe LiveCycle Designer as an easy to use, flexible tool for designing forms
• Adobe LiveCycle Designer is fully integrated into the SAP's IDEs: SAP NetWeaver Development Studio (Java) and ABAP Workbench
• Graphics (BMP, JPEG, GIF, PNG, EXIF) can be included into forms directly – no conversion required
• Objects (including texts) can be rotated
• Different page orientations (landscape, portrait) are possible within one form • Graphical elements can be included in forms
• Forms can be created so that they conform to accessibility standards • Complex layout elements can be shared between form developers • Existing PDF or Word documents can be imported
• TrueType Fonts can be used; installation requires no upload
• Barcodes can be printed on all printers of types Postscript, PCL, PDF, or Zebra
• Mailing and faxing is easier
• Forms are regular Repository objects with standard transport and versioning • Interactive scenarios and integration into browser-based applications are
Lesson Summary
You should now be able to:
• Name relevant parts of the architecture of the tool “Interactive Forms” • Name the steps to create a printing scenario with the tool “Interactive Forms”
Unit Summary
You should now be able to:
• Name relevant parts of the architecture of the tool “Interactive Forms” • Name the steps to create a printing scenario with the tool “Interactive Forms”
Test Your Knowledge
1. An interface can exist without a form.
Determine whether this statement is true or false.
□ True □ False
2. A context can exist without a form.
Determine whether this statement is true or false.
□ True □ False
3. The form layout can include elements from the context.
Determine whether this statement is true or false.
□ True □ False
4. A J2EE engine is required for interactive scenarios only.
Determine whether this statement is true or false.
□ True □ False
5. A function module is generated whenever a PDF-based form is printed.
Determine whether this statement is true or false.
□ True □ False
Answers
1. An interface can exist without a form. Answer: True
An interface is an independent Repository object and, as such, can exist without a form that makes use of it.
2. A context can exist without a form. Answer: False
A context is always part of a form.
3. The form layout can include elements from the context. Answer: True
Most of the dynamic elements of a form typically come from the context. 4. A J2EE engine is required for interactive scenarios only.
Answer: False
A J2EE engine is also needed for print scenarios, as Adobe document services need to be deployed on the J2EE engine.
5. A function module is generated whenever a PDF-based form is printed. Answer: False
A function module is generated only when a PDF-based form is activated. This function module is called whenever a PDF-based form is processed.
Unit 2
Interface
Unit Overview
Every PDF-based form needs to have an interface; it is the link between the ABAP program and the form. The program can pass data to the form only if it is defined in the interface, and (most of) the dynamic data used in the form layout will be defined in the interface. This unit walks you through the process of creating an interface that can then be used in any number of forms.
Unit Objectives
After completing this unit, you will be able to: • List the components of an interface • Create and design an interface for a form
Unit Contents
Lesson: The Interface as the Link Between Program and Form ... 14 Exercise 1: The Interface as the Link Between Program and Form .. 23
Lesson: The Interface as the Link Between Program and
Form
Lesson Overview
When you create a PDF based form, you must first start with the interface, as it determines which fields are available in the form. This lesson will show you how to create interfaces.
Lesson Objectives
After completing this lesson, you will be able to: • List the components of an interface
• Create and design an interface for a form
Business Example
A travel agency wants to print invoices for their customers' flight bookings, using the tool “Interactive Forms”. An application program is available, but not the form with its interface.
Types of an Interface
Figure 5: Interface: Properties
To access interface maintenance, use transaction SFP. Alternatively, use transaction SE80 and choose Other object. Choose the More tab page and select
Interface. In the example above, the interface is called BC480.
On the Properties tab page you determine the type of the interface. These types differ in the number and types of parameters and other elements they have. The types “ABAP Dictionary based” and “Smart Forms compatible” are used for print scenarios, whereas the type “XML schema based” (which was introduced in SAP NetWeaver 2004s) is primarily used for Web Dynpro scenarios.
If you create an interface to be used in an ABAP print program, you should choose “ABAP Dictionary based”. While it is possible to use the Smart Forms compatible interface type (for the sake of keeping an old print program without changes), it is not recommended to do so because:
• You will get wrong print parameters (for example, for the cover page) and XSF/XDF parameters that cannot be used any more.
• If the spool job contains several PDF documents, you will get only one back. • Only the “ABAP Dictionary” interface will allow you to determine settings
for the Business Communication Service.
Parts of an Interface: Types “ABAP Dictionary” or
“Smart Forms”
By double-clicking on one of the nodes in the interface tree on the left-hand side of the screen, an area opens up in the right-hand side that lets you enter details. What you can enter here is what you would enter for an ordinary function module in the Function Builder (transaction SE37):
• Parameter name
• For type assignment, TYPE is the only option (in interfaces that result from a Smart Form migration, you might also use LIKE.)
• Type name: You can enter ABAP types here (c, i, n, etc.) and Dictionary types (like data elements or tables).
• As several forms can use the same interface, you should think about including optional parameters that might not always be needed in all forms. This will help you to keep the number of interfaces small.
• If you set the Pass Value flag, a copy of the parameter will actually be passed from the program to the form (not just the address). Such parameters can be changed in the interface coding; the original value remains untouched. Parameters with this option checked will slow down performance, particularly in the case of large parameters (such as internal tables). • For non-structured parameters, you can also specify a default value, which
will be used if the program does not pass on a value for that parameter. All parameters with default values are implicitly optional.
The import parameters defined in the interface can be passed from the application program to the form at runtime, and vice versa for export parameters.
A form interface of the type “ABAP Dictionary” has only one default import parameter (/1bcdwb/docparams of type sfpdocparams). It is used to determine a form's locale (language and country) and whether the form will allow
interactive features. The default export parameter is /1bcdwb/formoutput of type
fpformoutput. This parameter has to be evaluated in the calling program if the
resulting document needs to be handled by the program itself. Export parameters can be added only for those interfaces that are compatible with Smart Forms. If an interface is compatible with Smart Forms, you might also have tables parameters. You should use them only if you have an internal table that needs to be changed with ABAP coding within the form.
Exceptions that you declare in an interface can be raised in ABAP coding of a form. They are based on the traditional exception concept (not the class-based concept that was introduced in SAP Web Application Server 6.10).
You raise an exception as such: RAISE <exception>. (Alternative:
If an exception is raised in the interface coding, it will actually be raised in the generated function module. You can evaluate exceptions by querying sy-subrc in the ABAP application program.
Figure 7: Global Definitions
There are also parts to an interface that are actually invisible from outside, that is, they cannot be accessed from the application program. Among them are the global definitions, initialization coding, and currency/unit fields.
In the global definitions, you have the following nodes:
• Global fields: You can set the values of global fields by specifying a default value or by using initial ABAP coding. In migrated Smart Forms, you can also use them in program line (ABAP) nodes. Global fields can be integrated in the form layout.
• Field symbols: Field symbols might act as placeholders for variables. They are useful in dynamic programming and for speeding up the processing of internal tables. In the form, they can be used in the same places as global fields, although the coding differs.
In PDF based forms, values can be assigned to field symbols in ABAP coding.
For details on how to use field symbols in ABAP coding, check the ABAP documentation, keyword FIELD-SYMBOLS.
• Global types: If your global fields (or any fields that you might declare within ABAP coding) need types other than ABAP types (i, n, f, c, p,and so on) or Dictionary types, you can create local types in the editor that opens when you choose Types. For details on how to create local types, check the ABAP documentation, keyword TYPES.
Figure 8: Initialization
During initialization, data coming from the program can be changed before it is sent to the form. In forms that have not been migrated from Smart Forms, initialization is the only time when ABAP coding can be executed.
Even if the initialization coding makes use of form interface fields or global fields, you still have to make them known to the initialization coding. Enter those fields that you read from under Input Parameters, and those that you set under Output
Parameters. You can also work with local variables that you create with the DATA
statement. Note, however, that these local variables are not known outside the initialization coding. In particular, they cannot be used in the form layout. The distinction between input parameters and output parameters is made only for structuring purposes. It has no effect on the potential for modifying parameters, as both input and output parameters are passed to the initialization coding by reference. As a consequence, changes of input parameters are permanent. System fields of the ABAP system structure SYST (sy-...) do not need to be declared, but can be used directly in the coding. System fields should not be changed.
In the initialization coding, you can call form routines that you have created in the interface: PERFORM ... Form routines make sense for coding that needs to be executed several times. You define form routines by using the ordinary ABAP syntax FORM xyz... ENDFORM.
Figure 9: Currency and Quantity Fields
ABAP distinguishes between internal and external representations of currencies and quantities. Whether or not decimals are included in the output format depends on the reference field of the amount. For example, the internal digit of 1000 might be 10.00 USD or 1000 JPY when printed. For structures or table types, these references are typically described in the ABAP Dictionary and evaluated automatically on screens. (To be more precise: information on decimals of currencies and quantities can be found in tables TCURX and T006. These tables are automatically evaluated whenever Dictionary reference fields are used.)
As of SAP NetWeaver 2004, this information – even if it is available in the Dictionary – cannot be evaluated for any fields from the form interface. You must explicitly give a reference field for all currency and quantity fields that you want to print in your form. Only then will you have correct decimals.
Use the value help (F4) to enter the relevant currency and quantity fields. Then continue to select appropriate reference fields. This will frequently, but not necessarily, be a field of the same structure. Finally, determine for every field whether it is a currency or a quantity field.
As of SAP NetWeaver 2004s, the currency and quantity information will be evaluated automatically. You can still set reference fields for your interface fields if you want to override the Dictionary settings.
XML Schema Based Interface
Figure 10: XML schema based interface
If you want to create an XML schema based interface, you must have a suitable XSD file to upload. Go to the Properties tab to upload your schema. (Typically, an XML based interface is not created manually, but generated from a Web Dynpro application.)
Apart from the import parameter /1BCDWB/DOCPARAMS, an XML interface has only one more import parameter, /1BCDWB/DOCXML. All the business data that is transferred to the form at runtime must be passed over with this XSTRING
parameter. It is not possible to add further parameters to an XML form interface. As you cannot have ABAP initialization coding either, you cannot create global data, types, field-symbols, or form routines.
Exercise 1: The Interface as the Link
Between Program and Form
Exercise Objectives
After completing this exercise, you will be able to: • Create and design an interface for a form
Business Example
A travel agency wants to print invoices for their customers' flight bookings, using the tool “Interactive Forms”. Designing the interface is the first step.
Task 1:
Create an interface.
Please stick closely to the exercise description, because at the end of the exercise, a program will check whether your interface contains errors.
1. Create an interface: ZBC480_##. Save it in package ZBC480_## (## stands for your two-digit group number). The reference solution for this exercise is interface BC480.
Task 2:
Determine the type of the interface.
1. Make sure your interface is ABAP Dictionary based.
Task 3:
Create import parameters.
1. Create an obligatory structure, IS_CUSTOMER, of type scustom.
2. Create an obligatory internal table, IT_BOOKINGS, of type ty_bookings. 3. Create an optional parameter, IV_IMAGE_URL, of type STRING. Make it a
call-by-value parameter. (This parameter will later contain a hyperlink for an image – a company logo.)
4. Create a parameter, IV_SENDING_COUNTRY, of type adrc-country with the default value 'US'. (This parameter will later determine from which country the invoice is to be sent, so that the customer address can be formatted accordingly.)
Task 4:
Create global data.
1. Create the constant GC_CLERK of type text20. Assign the value Dupont. 2. Create the variable GT_ADDRESS of type tline_tab.
Task 5:
Create initialization coding.
1. Determine the URL for the company logo. If IV_IMAGE_URL has no value, assign the address http://wts.wdf.sap.corp:1080/portal/Image/sap_logo.gif. 2. The global field GT_ADDRESS should contain the formatted
customer's address. To achieve this, call function module
CUSTOMER_ADDRESS_TO_ITF and set the parameters appropriately.
Task 6:
Check your interface for correctness. 1. Activate your interface.
2. Run report SAPBC480_CHECK. Green, yellow, and red indicators will show you which of your fields are correct, not quite correct, or wrong.
Solution 1: The Interface as the Link
Between Program and Form
Task 1:
Create an interface.
Please stick closely to the exercise description, because at the end of the exercise, a program will check whether your interface contains errors.
1. Create an interface: ZBC480_##. Save it in package ZBC480_## (## stands for your two-digit group number). The reference solution for this exercise is interface BC480.
a) Start transaction SFP.
b) Select Interface. Enter the name ZBC480_## and choose Create. c) In the following window, enter a description and press Enter.
d) In the following window, enter ZBC480_## as the package and press
Enter.
e) In the following window, press F4 to select the workbench request the instructor has created for you.
f) Continue by pressing Enter.
Task 2:
Determine the type of the interface.
1. Make sure your interface is ABAP Dictionary based.
a) This is automatically the case when you create an interface. Go to the
Properties tab to check.
Task 3:
Create import parameters.
1. Create an obligatory structure, IS_CUSTOMER, of type scustom.
a) Choose the Interface tab. On the left side, double-click Import. On the right side, choose the icon with the white sheet to append a new row. b) In the column Parameter name, enter IS_CUSTOMER.
c) In the column Type assignment, select TYPE. In the column Type name, enter SCUSTOM. Leave the remaining columns empty.
2. Create an obligatory internal table, IT_BOOKINGS, of type ty_bookings. a) See previous task.
3. Create an optional parameter, IV_IMAGE_URL, of type STRING. Make it a call-by-value parameter. (This parameter will later contain a hyperlink for an image – a company logo.)
a) See previous task.
4. Create a parameter, IV_SENDING_COUNTRY, of type adrc-country with the default value 'US'. (This parameter will later determine from which country the invoice is to be sent, so that the customer address can be formatted accordingly.)
a) See previous task, but deselect the Pass Valueoption. Also, enter 'US' (with single quotes!) in the Default Value column.
Task 4:
Create global data.
1. Create the constant GC_CLERK of type text20. Assign the value Dupont. a) Go to the Interface tab. On the left side, double-click on Global Data.
On the right side, choose the icon with the white sheet to append a new row.
b) In the Variable name column, enter GC_CLERK. In the column Type
assignment, select TYPE. In the column Type name, enter text20. Enter
'Dupont' (with single quotes!) in the column Default Value. Check the option Constant.
2. Create the variable GT_ADDRESS of type tline_tab.
a) See previous task, but deselect the Constant option and leave the
Default value column empty.
Task 5:
Create initialization coding.
1. Determine the URL for the company logo. If IV_IMAGE_URL has no value, assign the address http://wts.wdf.sap.corp:1080/portal/Image/sap_logo.gif. a) Go to the Output parameters and choose the icon with the white sheet
to append a new row. Enter IV_IMAGE_URL. b) In the ABAP editor, enter the following coding:
IF iv_image_url IS INITIAL. iv_image_url =
'http://wts.wdf.sap.corp:1080/portal/Image/sap_logo.gif' ENDIF.
2. The global field GT_ADDRESS should contain the formatted customer's address. To achieve this, call function module
CUSTOMER_ADDRESS_TO_ITF and set the parameters appropriately. a) Go to the Input parameters and click twice on the icon with the
white sheet to append two new rows. Enter IS_CUSTOMER and IV_SENDING_COUNTRY.
b) Go to the Output parameters and click on the icon with the white sheet to append a new row. Enter GT_ADDRESS.
c) In the ABAP editor, enter the following coding:
CALL FUNCTION 'CUSTOMER_ADDRESS_TO_ITF' EXPORTING is_customer = is_customer iv_sending_country = iv_sending_country IMPORTING et_address = gt_address.
Task 6:
Check your interface for correctness. 1. Activate your interface.
a) Press Ctrl+F3.
2. Run report SAPBC480_CHECK. Green, yellow, and red indicators will show you which of your fields are correct, not quite correct, or wrong.
Note: The coding will not be examined.
a) Call transaction SA38 and enter SAPBC480_CHECK. Press F8 to start the report.
Lesson Summary
You should now be able to:
• List the components of an interface • Create and design an interface for a form
Unit Summary
You should now be able to:
• List the components of an interface • Create and design an interface for a form
Test Your Knowledge
1. Every form interface is compatible with Smart Forms.
Determine whether this statement is true or false.
□ True □ False
2. The values of import parameters can always be changed in the initialization coding of a form interface.
Determine whether this statement is true or false.
□ True □ False
3. Interfaces can be maintained with transaction SE80.
Determine whether this statement is true or false.
□ True □ False
4. You can define your own local types for the import parameters of a form interface.
Determine whether this statement is true or false.
□ True □ False
5. You can define your own local types for the global data of a form interface.
Determine whether this statement is true or false.
□ True □ False
6. Import parameters of a form interface are always optional.
Determine whether this statement is true or false.
□ True □ False
7. Initialization coding is executed by Adobe document services.
Determine whether this statement is true or false.
□ True □ False
Answers
1. Every form interface is compatible with Smart Forms. Answer: False
You can decide whether a form interface should be compatible with Smart Forms. You do this on the Properties tab.
2. The values of import parameters can always be changed in the initialization coding of a form interface.
Answer: False
Only those parameters with the Pass Value option selected can be changed. 3. Interfaces can be maintained with transaction SE80.
Answer: True
You can either use the standalone Form Builder (transaction SFP) or the version that is integrated into the ABAP Workbench (transaction SE80). 4. You can define your own local types for the import parameters of a form
interface. Answer: False
As the interface contains those parts of a form that are accessible from an ABAP program, you can use only Dictionary types or ABAP types. 5. You can define your own local types for the global data of a form interface.
Answer: True
You define your own local types with the ABAP command TYPES. 6. Import parameters of a form interface are always optional.
Answer: False
Import parameters of a form interface are optional only if explicitly marked as optional or if they have a default value.
7. Initialization coding is executed by Adobe document services. Answer: False
Initialization coding is executed by the ABAP processor, before the XML data stream is passed on to Adobe document services.
Unit 3
Context
Unit Overview
The context is essential, as it provides the source for data for a form. Apart from static elements, only those texts, fields, images, and so on can be included in the layout of a form that have been integrated into the form's context. However, the context should not be overloaded, as this will have a negative impact on printing performance.
This unit will teach you all the details of a form context, including how to create and maintain it.
Unit Objectives
After completing this unit, you will be able to:
• Effectively use transaction SFP to create a form context • Create a form context using an existing interface
• Integrate folders, alternatives, graphics, and addresses into a form context • Create and integrate long texts into a form context
Unit Contents
Lesson: Form Context: Using and Extending a Form Interface ... 36 Exercise 2: Form Context: Using and Extending a Form Interface ... 61
Lesson: Form Context: Using and Extending a Form
Interface
Lesson Overview
Once you have created an interface, you can use it in a form. More precisely, the form's context makes use of the interface. It can be seen as a subset of the interface enriched with some form specific information. The form context contains the concrete data for the form. (If you use an XML-based interface - typically within a Web Dynpro form scenario - the form does not contain a context. In that case, all data from the interface is available in the form directly.)
This lessons shows you how to create a form context, use an existing form interface, choose the elements that are needed in the form, and add additional elements like texts or graphics.
Lesson Objectives
After completing this lesson, you will be able to:
• Effectively use transaction SFP to create a form context • Create a form context using an existing interface
• Integrate folders, alternatives, graphics, and addresses into a form context • Create and integrate long texts into a form context
Business Example
A travel agency wants to print invoices for their customers' flight bookings, using the tool “SAP Interactive Forms by Adobe”. A program and interface are available, but no form yet.
Form Properties
To access the Form Builder, use transaction SFP. Alternatively, use transaction SE80 and choose Other object. Then choose the More tab page and select Form.
Figure 11: Form Properties
The following details are entered on the Properties tab: • The description of the form
• The layout type. This is relevant only if you create forms with scripting for interactive scenarios. You can choose between the Active Component Framework (ACF), which requires additional software installation (see SAP Note 766191) on the user's PC, and the newer version, Zero Client Installation (ZCI), which requires no extra installation, but a recent Adobe Reader. See SAP Note 955795 for details.
• The name of the interface to be used: Double-click on its name to display or change it. Be careful when you change a form interface that is used in a form; you will not get a warning if you do so, even though you might corrupt the form.
The name of the package will automatically be added to the form properties when you first save the form. If you want to change the package assignment later, choose Go to → Object directory entry.
Note: As a form with an XML-based interface does not contain a context, all of the following information pertains to forms with ABAP Dictionary or Smart Forms compatible interfaces.
General Handling of the Context
The screen on the Context tab of transaction SFP is split into four areas: • Interface
All fields that are displayed in the Interface area (all interface fields plus the system fields sfpsy-date, sfpsy-time, sfpsy-username, sfpsy-subrc) can be selected for the context by dragging and dropping them there. If your interface is compatible with Smart Forms, you will have the Smart Forms system fields (SFSY-...) instead.
• Context
The context area contains those elements that will be available in the form layout. These fields are a subset of the interface, and include additional elements like graphics or texts. You can create new elements by right-clicking on the context.
• Properties of interface field
Double-clicking on a field from the interface will display its details in the bottom left area.
• Properties/details/conditions of context element
Double-clicking on an element from the context will display its details in the bottom right area. For example, you would set the source for an image or the name of an external text here.
From NetWeaver 2004s on, for fields with Dictionary reference, their texts can automatically be integrated into the form layout to be used as captions. As the Dictionary (or more precisely: the data element) offers four different kinds of texts, you can choose which one to use
Figure 13: Using the Interface
You can drag and drop elements from the interface tree into the context tree. You can achieve the same by right-clicking in the context tree and selecting Create →
Data, Structure or Loop.
If you use a Smart Forms-compatible interface, you can also integrate ABAP system fields (sy-...) by right-clicking in the context tree and selecting Create
→ Data or Structure.
Original fields from a structure or an internal table will be marked as generated. It is possible to drag and drop a field into an internal table, which, for example, allows you to have individual long texts for every dataset.
It is possible to name objects in the context in a different way from those in the interface. Double-click on the element and rename it in the Properties section in the bottom right area.
If you include fields from the interface with ABAP Dictionary reference, their Dictionary descriptions will automatically be referenced. Consequently, you cannot change the texts for these fields and you do not have to translate them separately.
You can create new nodes, for example texts and graphics by using the context menu.
In the figure above, the graphic node LOGO was created in this form.
The order in which you integrate fields in the context is irrelevant unless you nest one element in another.
Fields that are not required can be set to inactive (using the right mouse button). They will have a cross in the Inactive column. Deactivating a field in the context means that it will not be part of the XML data stream (XFD). Thus, performance can be improved. Note, however, that deactivating parts of the context does not turn mandatory interface fields into optional fields; that is, the print program will nonetheless have to pass them to the form's interface. Setting fields that do not come from the interface (that you define in the context) to inactive makes sense for testing scenarios.
Tables
Figure 14: Detour: XML Representations of Internal Tables
Internal tables in the context are displayed as if they were always nested; this reflects the way they are represented in the XML schema definition (XSD). The XSD describes how data must be structured so that it will be considered valid. As Adobe LiveCycle Designer requires this XSD, SAP's transaction SFP automatically generates it from the form context. It cannot be changed manually. In the XSD representation of an internal table, the structure DATA reflects the line type. Hence, if you want to include other fields in the internal table, you must create them in the structure DATA.
You can integrate an internal table into the context by dragging it from the left-hand side to the right-hand-side. Alternatively, choose Create → Loop from the context menu of the context.
Figure 15: Internal Tables (Loops) in the Context
On the Properties tab, you can specify which lines of the internal table will be processed in ABAP and passed to the XML data stream. The corresponding ABAP command is:
LOOP AT it INTO wa FROM <r1> TO <r2>.
You can also give a WHERE clause, stating that a row will be part of the XML data stream only if a field has a certain value. The corresponding ABAP command is: LOOP AT it INTO wa WHERE <field> = <value>.
A WHERE clause is in particular helpful if you want to nest one table T2 into a table T1. Let's assume the ABAP program passes two internal tables to the form: one with all customers (T1) and one with all bookings (T2). Within the document, you would like to print the bookings just for the customer for whom the form is printed. In that case, you would nest T2 into T1 and add a suitable WHERE clause for T2, like CUST_NUMBER = T1-CUST_NUMBER. This would result in only one XML table – which can later be integrated into the layout in a very convenient way. On the Control Level tab, you can create control levels to group tables by data fields. In this way, you can, for example, define a nested output for a flat internal table.
Group levels make sense only if the data is sorted according to these levels. You can sort the table yourself (in the ABAP coding of the print program or in the initialization coding of the form), in which case you select Already sorted on the Properties tab. Or you can have the table sorted automatically before form
rendering. Mind, however, that the latter option is possible only if the table is either defined as a global interface field or as a call-by-value import parameter. (A call-by-reference import parameter is read-only.) Please note that control levels were introduced in SAP NetWeaver 2004s.)
If you want to have only one specific row of an internal table, you should not use the entire internal table with a WHERE clause or an index. Instead: right-click on the context, choose Create → Single Record, specify the internal table to use and set either the row number or the key to identify the row. This way, the handling in Designer will be easier, as the result will be treated as a structure rather than an internal table. (You need at least SAP NetWeaver 2004s for single records.) The equivalent ABAP command is READ TABLE. You can query the result of this single record access with the help of the field SFPSY-SUBRC, which is a copy of SY-SUBRC.
Conditions and Alternatives
Figure 16: Conditions for Context Elements
You can enter conditions for most node types of the context. If a condition for a context element fails to be correct at runtime, the element field will not be part of the data stream. Conditions are also possible for more complex elements that have “children” in the context tree (structures, internal tables, or folders). If such a condition fails at runtime, none of the subordinate elements will be part of the data stream.
Conditions help to reduce data traffic. They also help in hiding fields from the layout.
All of the fields from the interface (even those that you do not drag and drop to the context) are known to all context fields and can be used in conditions. You cannot refer to other context fields or to ABAP system fields.
You can see at a glance which context nodes have conditions, as they will have an additional condition symbol next to the node symbol itself.
Figure 17: Including Alternatives
An alternative is a node with two subnodes (TRUE and FALSE), each of which can contain further subnodes of any type. The condition(s) you enter when you choose the Alternative Conditions button determine which of the two subnodes will be processed at runtime. If the condition is met, the TRUE node is processed, including all of its subnodes. If the condition is not fulfilled, the FALSE node is processed together with its subnodes. This query is similar to that of the ABAP commands IF and ELSE. You can enter the same kinds of conditions as for other nodes.
Caution: The meaning of the condition for an alternative differs from the meaning of conditions of other nodes. The condition for an alternative determines whether the TRUE and FALSE nodes will be part of the resulting data stream. The condition of an alternative does not determine whether the alternative itself is evaluated or not. (The logic of the alternative is always processed.)
Folders
The more detailed a form becomes, the more difficult it is to get a clear overview of the hierarchy of nodes. To make the hierarchy easier to understand, you can organize nodes in folder nodes. Folders can be collapsed and expanded so that you will see only those nodes in the context that you actually need to see.
Figure 18: Including Folders
Examples of the usage of folders:
• A dunning form has different dunning texts, of which only one is to be passed on to the data stream at runtime, depending on the reminder days exceeded. You can create these texts (with individual conditions) and group them into a folder.
• Several nodes share the same condition(s). Instead of setting the condition(s) individually for each node, you can create a folder and then assign the condition(s) to this folder only. They will be passed on to its nodes. Folders make working with Adobe LiveCycle Designer easier, too, as they help you to organize your layout.
Graphics
In the context, you can also define graphics. To do so, right-click on the top node of the context and choose Create → Graphic.
In the attributes section of the lower right part of the screen, specify details of the graphic. In particular, specify the graphic type:
• Graphic Content: If you select this type, you must specify a field name from
the context that will contain the data of the graphic at runtime. Permissible types are STRING (graphical data is Base64-coded) or XSTRING (for binary-coded graphical data). You must also enter a valid MIME type, such as such as 'image/bmp' or 'image/jpeg'.
• Graphic Reference: This type allows you to specify the graphic's
address dynamically. You must enter the details by choosing the URL button. You can split the URL into dynamic parts (which are represented by individual STRING variables from the interface) and static parts (literals), which must be enclosed in single quotes. The different parts of the graphic URL can be separated by a delimiter, which you can set. In the above example, possible locations of the image at runtime would be http://www.sap.com/IMAGES/logo1.bmp or http://www.sap.com/IMAGES/logo2.gif.
You can include images of the most popular types: Windows Bitmaps (*.bmp), JPEGs (*.jpg), TIFFs (*.TIF), PNGs (*.png), and GIFs (*.gif – animated GIFs are not supported). Adobe LiveCycle Designer 7.0 or higher lets you include graphics of type EXIF, too.
Including Texts
In a form context, four types of long texts can be included: • Addresses from the Business Address Services • Text modules (Smart Forms texts)
• Include texts (SAPscript texts) • Dynamic texts
All these texts will automatically be converted by transaction SFP into a special format that can be evaluated by Adobe document services: XHTML.
Note: XHTML is an XML standard that extends HTML 4. (HTML = Hypertext Markup Language – commonly seen as the standard publishing language of the World Wide Web.) XHTML can be viewed in most Web (HTML) browsers.
Addresses
Figure 20: Formatted, Country-Specific Addresses
Instead of using their own tables for address information, many applications now access Business Address Services (BAS). In the Business Address Services, addresses are identified by means of numbers.
Before SAP Web Application Server 6.10, BAS was known as Central Address Management.
The addresses that you integrate into your form's layout will be formatted in accordance with country-specific conventions (based on ISO 11180 and the guidelines of the Universal Postal Union). For detailed information, see the documentation on the function module ADDRESS_INTO_PRINTFORM.
In the context, you can create nodes that make use of Business Address Services. You do not need to know the technical details of Business Address Services, or worry about the correct formatting of the addresses.
Address nodes will be rendered as regular texts in the form. Some of the relevant fields in Business Address Services include:
Address type:
• Company addresses: Typical examples are delivery addresses or company
codes. These addresses are uniquely identified by their address numbers. In the context, you must specify the value of the address number. It must be a ten-digit character field. Typically, this is an interface parameter.
• Private addresses: Addresses of this type are assigned to one natural person,
along with other associated attributes, such as the form of address. Because a person can have more than one address, enter both the address number and the person number for identification. Both must be ten-digit character fields, and both are usually interface parameters.
• Contact person in company: These are personal addresses in companies,
which means they have additional attributes, such as the department or the room number. You identify such an address by means of the address number and the person number. Both must be ten-digit character fields, and both are usually interface parameters.
• Define Dynamically: If you want to determine the address type at runtime,
enter the name of an appropriate interface parameter. At runtime, this parameter must be filled with 1, 2, or 3.
You must specify the sending country. If you enter an interface parameter here, the country can be determined dynamically at runtime. If, at runtime, the address is found to be domestic, the addressee's country will not show.
If the system does not find an address with the numbers specified in Business Address Services at runtime, the generated function module of the form terminates with an error message.
For addresses that have both a post office box number and a street address, use the drop-down list to determine which one to use. You can also choose Define
dynamically, in which case you must also enter the name of a field, which at
runtime contains X (street) or a space (post office box).
In the Priority of Lines field, you can determine which part of the address is first suppressed if there is not enough space for the address node. For example, A stands for form of address, P for an obligatory empty line, and D for department. For more information, see the documentation for the function module ADDRESS_INTO_PRINTFORM.
Text Modules and SAPscript Texts
Figure 22: Long Texts from the Database
In some cases, it makes sense to store texts not in the form itself, but centrally in the database. The form then contains only a reference indicating which text should be used at application program runtime. This method has the following advantages: • You need to create the texts only once and can then reuse them as required. • You make changes centrally only once without having to modify the actual forms. (The reference in the form remains unchanged.) Typical examples include headers (company address), footers (company information like board members and so on), and whole pages containing introductions or terms of trade.
You can use text modules of Smart Forms and also include texts (that is, SAPscript texts). Run transaction SMARTFORMS (for text modules) orSO10 (for include texts).
With regards to PDF-based forms, the main difference between the two text types is that text modules are client-independent and have an automatic link to the Transport Organizer, whereas SAPscript texts are client-dependent and must be manually included in a transport request.
Figure 23: Creating Text Modules
The maintenance transaction for text modules is SMARTFORMS. Select Text
module on the initial screen and then choose Display, Change or Create, depending
on what you want to do. From this screen, you can also copy, rename, or delete existing text modules. To do this, choose the appropriate button from the toolbar or use the Text Module menu.
Since text modules are integrated with the SAP transport system, you must assign them to a package. You do this when you first save your text module.
You must assign a style to each text module on the Management tab. The default style is System.
You can enter text in the same way as you would in any common word-processing system. Alternately, you can switch to full-screen mode by choosing the
appropriate button.
You can use the clipboard by selecting text blocks with the mouse and then choosing the Cut, Copy, or Paste buttons. This way, you can copy text sections between different text modules.
Lines in text modules are broken automatically at runtime depending on the width of the form element where they are included. The editor assumes a certain standard width and breaks your text as you type it in, but this does not influence line breaks in the output.
If you want to determine line breaks manually, you have two options:
• You can use the Enter key to create a new paragraph, which may then have a different format than the preceding one.
• Shift+Enter allows you to create a line break within a paragraph.
The Paragraph mark on/off button allows you to determine whether you want to display nonprinting characters (blanks, tabulators, paragraph marks, and line breaks).
Though technically it is possible to include hyperlinks in a text module, they will not show in the resulting PDF that includes the text module. (This is true as of SAP Web Application Server 6.40.)
The full-screen editor also allows you to switch to the old line editor used by SAPscript, which technically enables you to type in SAPscript commands. However, all SAPscript commands will be ignored at runtime, so it is best not to use this option.
You can format selected text sections. These text sections are then displayed in the editor as they will appear when printed (WYSIWYG = What You See Is What You Get).
For each paragraph, you can choose a paragraph format from the selection list in the editor. A paragraph format is a collection of format settings, such as tabs, type of justification, and so on. The paragraph formats available for selection in the list depend on the style you have chosen.
All formats have a one- or two-digit name, which is defined in the style. An asterisk (*) indicates the default format.
The system automatically displays the set format at the current cursor position in the paragraph and character format list. You therefore only need the Display
formats function if you want to obtain detailed information on the format, or if
text has been formatted using several character formats.
Figure 26: Text Modules: Inserting Fields
Frequently, text modules contain not only static text, but also variable data, referred to as fields. In the editor, fields cannot be inserted or manipulated directly. Instead, use the relevant buttons to insert, edit, or delete a field.
All fields start and end with an ampersand, such as &SFPSY-DATE&. You can enter the following fields:
• Fields that are used in a form interface (typically containing business data) • sfpsy fields
• Fields from Dictionary structure syst, such as sy-mandt (client) or sy-sysid (system ID): Note that not all fields make sense. In particular, fields used in list processing, like sy-pagno, are not filled by the system and should not be used.
Field names are case-insensitive.
Formatting options as they can be used in SAPscript or Smart Forms (like offsets or the “no zeroes” option) will be ignored in texts when included in PDF-based forms.
Be sure to include only those fields into your text that are actually known at form processing time, that is, those that are defined in the form interface that is actually used. If, at runtime, a field turns out not to be defined, the program execution will terminate. SFPSY fields can always be used in text modules, even if they have not been included in the context. The syntax check of the context includes a syntax check of the referenced text module only as of SAP NetWeaver 2004s.
Figure 27: Including Text Modules
If you want to include a text module into a context, right-click somewhere in the context tree and choose Create → Text.
To determine which text module should actually be taken, specify the name and the language. Both of these can be determined with fixed values or dynamically. In the first case, enter the name and language in single quotes. In the second case, enter the names of interface fields.
If you determine name and language of the text module dynamically, you cannot check from within form maintenance whether the fields are filled with appropriate values at application program runtime. If you want to avoid program termination in case the text does not exist, select No error if text not available.
If you do not enter a language, the form's language will be used.
The text module's style determines the available paragraph and character formats. The following options are available:
• Copy Style From Text Module actually means that you want to use the text
module's style.
• You can also specify a different style, which will then be applied to the text module. As the style cannot be set dynamically, you do not enclose the style in quotes.
• If you choose neither of these options, no style will be applied (not even Smart Form's standard style System), which will result in plain text.
Figure 28: Including SAPscript Texts
If you want to include a SAPscript text (also called include text) into a context, right-click somewhere in the context tree, choose Create → Text, then set Text
Type to Include text.
You need to specify the text name, the text object, the text ID, and the text language. All of these can be entered as literals (enclosed in single quotes) or as fields (which must be known from the interface). If you do not enter a language, the form's language will be taken.
If you select No error if text not available, the generated function module will not terminate if the text specified is not found at runtime.
Note that all SAPscript commands in SAPscript texts will be ignored. In particular, this means that nesting SAPscript texts is not possible.
As to the text formatting, SAPscript styles assigned to the text will be ignored. All paragraph formats and character formats of an include text are interpreted as they are defined in the style (Smart Style) that you can enter in the Style field. For example, the paragraph format B in a SAPscript text might mean bold, but in the Smart Style it could mean small. Each paragraph with format B in the text would therefore be printed in small text. If a format is used that is not defined in the style that you enter in the context, it will be ignored.
You can override the paragraph formatting of include texts:
In the Standard Paragraph field, you can select a paragraph format of the Smart Style that you enter in the Style field. This format is then used for all paragraphs of the SAPscript text that are formatted using the standard paragraph (*). If you are familiar with SAPscript commands: an entry in this field corresponds to the PARAGRAPHaddition of the INCLUDE command.
You use the First Paragraph attribute to set a paragraph format for the first paragraph of the include text - independently of how the paragraph is actually formatted in the include text (corresponds to the NEW PARAGRAPH addition of the SAPscript command INCLUDE). If the Standard Paragraph field remains empty, all standard paragraphs in the include text also adopt this paragraph format. Now that you know how to include Smart Forms text modules or SAPscript texts, let's summarize the main differences. If you have a choice, you should normally opt for Smart Forms texts.
Dynamic Texts
Apart from addresses, text modules, and SAPscript texts, you can include a fourth type of long texts into the context: dynamic texts. In this case, you must specify an internal table with line type tline that will contain the text in ITF format at runtime. tline consists of two columns: column tdformat contains the name of the paragraph format, and tdline the content of the line. (In other words, a dynamic text looks exactly like a text module or a SAPscript text in the line editor.)
Figure 30: Dynamic Texts
If you enter an astersik (*) as the paragraph, the default paragraph will be taken from the style (Smart Style) that you specify in the context.
If you want to have continuous text, make sure to enter a paragraph format only for the first line. You can then add as many lines to the internal table as you like, using only the tdline column. tdline can contain up to 132 characters. Independent of how many characters you enter, the resulting text in the form will have one paragraph.
If you want to apply character formats to some parts of the text, look up the name of a suitable format in the style to be used (it will always have a one- or two-digit name). Put this name in angle brackets, then write the text that needs to be formatted, and close the formatting with </>. For example, if a style contains the character format AB, you might format parts of a text like this: irrelevant <AB>formatted</> irrelevant.
Figure 31: Including Dynamic Texts
If you create a dynamic text in a form context, make sure to give the name of the internal table (which has line type tline) in the Field field. Do not include the internal table as an independent context node. It should be referred to only in the dynamic text.
The style that you specify for a dynamic text must be a Smart style – that is, a style that can also be used for text modules.
Addresses Without Business Address Services
If your application makes no use of the Business Address Services but you still want to have country-specific addresses, you must use ABAP coding to achieve this. It is possible to do this in the application program or in the initialization coding of the interface. The example here describes the latter option.
