SAP Adobe Form - Data Binding using Global Data and use of FM FP_FUNCTION_XML_INTERFACE

[Abhijeet]

As per the Adobe LiveCycle Designer 10.0.1 for SAP documentation, A global field is a field used in a form where the same information, like an invoice number, needs to display in several places. By setting this field as global in the form design, we can easily reuse it wherever needed.

Global fields are very useful for repeating information in multiple places on a form. They help by reducing the amount of data sent and ensuring the same data appears consistently across the form.

Using the Global binding property, we can assign the same value to all form objects with the same name. When you make an object global, all objects with that name will share the same data during runtime. Because these global objects are linked to the same data value, changing the data in one global object updates it in all others with the same name.

Following table describes the details about global fields.

Point	Global fields
What happens	Designer shows the same value in all fields that have the same name.
Names of the fields	Names must be identical.
Run-time properties (such as the current page, number of pages, and current date/time)	You cannot add run-time properties to the field.
If you remove...	If you remove the global setting from one field, Designer removes the setting from all other fields with the same name.
Reference to nodes	Global fields can refer to nodes outside the current record.
Example of when to use	Use for information that is repeated in the form, such as customer name or address. The user enters the information once and the data automatically fills the other fields that are set to global.

Source: Adobe LiveCycle Designer 10.0.1 for SAP documentation

This blog explains how to use Function Module FP_FUNCTION_XML_INTERFACE instead of a normal form call and then binding the data to the fields using global data binding.

Pre-requisites steps to use FM: FP_FUNCTION_XML_INTERFACE

 This function module can be used as an alternative to the normal SAP adobe form call for global data binding, in which the input is the form name and data is in the XSTRING format. Function module details can be checked at: https://www.sapdatasheet.org/abap/func/fp_function_xml_interface.html

Implementation Steps:

• Create an Interface.
• Create a form.
• Add Required fields and select binding as Global Data
• Here, Field name is important as we are going to create an XML using the same field names. we can apply the global binding setting to the following types of objects:

1. check boxes
2. date/time fields
3. drop-down lists
4. image fields
5. list boxes
6. numeric fields
7. decimal fields
8. password fields
9. radio buttons
10. text fields
11. barcoded fields (excluding Paper Form Barcode)

• Create a driver program and add business logic to fetch the required data.
• Convert the data to XML format.
• Convert XML to XSTRING
• Call FP_JOB_OPEN – Set output parameters.
• Call FP_FUNCTION_XML_INTERFACE – Pass Form Name and XSTRING
• Call FP_JOB_CLOSE  

Consider an example: A company wants to print a HU label consisting of a HU number, a QR code for HU, and a barcode for HU. Here, only one field is required, and that’s the HU number, and the same can be bind to the text field, barcode, and QR code.

Let’s create a form and add a HU number text field. The below pop-up will be displayed once the data binding is selected as global data. Click OK and enter the field name.

I have added the field name as HU_NUMBER. Same name to be used while binding the QR code and barcode.

Add QR code & Barcode and bind using the same name.

Selection Screen: Enter the HU Number

Output:

Below is the code snippet which shows how to use the FM FP_FUNCTION_XML_INTERFACE.

REPORT ztest.

DATA:lv_text         TYPE string,
     ls_outputparams TYPE sfpoutputparams,
     lv_docxml       TYPE xstring.

SELECTION-SCREEN: BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-000.
PARAMETERS: p_hu(8).
SELECTION-SCREEN: END OF BLOCK b1.

START-OF-SELECTION.

  "prepare XML
  CONCATENATE
  '<XML_DATA>'
  '<HU_NUMBER>'
  p_hu
  '</HU_NUMBER>'
  '</XML_DATA>'
  INTO lv_text.

  "Convert to XSTRING
  CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
    EXPORTING
      text   = lv_text
    IMPORTING
      buffer = lv_docxml
    EXCEPTIONS
      failed = 1
      OTHERS = 2.
  IF sy-subrc <> 0.
  ENDIF.

  IF lv_docxml IS NOT INITIAL.

    ls_outputparams-preview = abap_true.

    CALL FUNCTION 'FP_JOB_OPEN'
      CHANGING
        ie_outputparams = ls_outputparams
      EXCEPTIONS
        cancel          = 1
        usage_error     = 2
        system_error    = 3
        internal_error  = 4
        OTHERS          = 5.
    IF sy-subrc <> 0.
    ENDIF.

    CALL FUNCTION 'FP_FUNCTION_XML_INTERFACE'
      EXPORTING
        formname       = 'ZTEST_F'
        /1bcdwb/docxml = lv_docxml
      EXCEPTIONS
        usage_error    = 1
        system_error   = 2
        internal_error = 3
        OTHERS         = 4.
    IF sy-subrc <> 0.
    ENDIF.

    CALL FUNCTION 'FP_JOB_CLOSE'
      EXCEPTIONS
        usage_error    = 1
        system_error   = 2
        internal_error = 3
        OTHERS         = 4.
    IF sy-subrc <> 0.
    ENDIF.
  ENDIF.

In this way, we can use an XML-based form interface whenever we have to bind the same field in multiple places. This kind of framework is more suitable for requirements like printing certificates or printing labels where the number of fields are less in number but required to be bind in multiple places.

The preparation of XML can be made dynamic based on the requirements. A new table with fields like key and value can be created with TMG and used in the driver program to prepare XML dynamically. This will ease the process of adding new fields in the form.

I’m looking forward to hearing more about XML interface-based forms. Feel free to comment and discuss.

Best regards, thanks for reading, and stay healthy.
Abhijeet Tikar

[Chad_He]

Dear Abhijeet Tikar,

Permit me to elaborate on my comprehension:

1. As an Import Data, it can't be used in different variable fields in one form.

2. When we use FM [FP_FUNCTION_MODULE_NAME], we can't transport data to global fields

That's why we have to use FM [FP_FUNCTION_XML_INTERFACE] to transport data to global fields.

So, is it the same as following method?

1. Import HU number to a import data

2. Set this HU number to a global field via routine in ADF.

3. Binding this global field to multiple fields on the form.

Chad

[vishal006]

Hi @Chad_He ,

You are correct, Your approach of setting a global field via routine and binding it to multiple fields in the form is practical. But I feel there are specific scenarios where this approach might face challenges compared to using global data binding directly, for instance:

Inter-Form Data Sharing:
Scenario: Scenarios where data needs to be shared between multiple forms or documents.

Issue: Setting global fields manually in one form does not automatically extend to other forms or documents. If your solution requires data sharing between multiple forms, manually setting global fields may not be efficient or feasible. Global data binding is typically scoped to a single form, and sharing data across forms might require a different approach or additional configuration.

Also, like you mentioned using import fields in interface like in case of @Abhijeet the HU_NUMBER we are having restriction on multiple form calling to have same importing parameters. We will have to maintain the consistency when calling multiple forms, but in case of global data binding i believe we are just concerned with the xml layout and the data in layout can be easily called with the FM FM [FP_FUNCTION_XML_INTERFACE] irrespective of the importing parameters.

@Abhijeet Even I am new to the global binding any views from your end would be helpful.

Thanks,
Vishal