- SAP Managed Tags
Introduction
Previewing print forms "locally" within the Adobe LiveCycle Designer is an essential feature. Otherwise, you spend too much time uploading the print form to the system to preview it online after every small change. However, not only changing the template and testing it straight away is a significant advantage. Simply adapting the XML sample data to see, for instance, how a field looks when containing a different value, longer text, etc., is beneficial in contrast to creating a new sample document within the system for this purpose.
By the way, if you are looking for details on this topic for SAP Sales/Service Cloud version 1 (formerly known as "Cloud for Customer"), you should have a look at this blog post: How to get XML data for local preview of print forms without output history.
Disclaimer
The procedure to extract XML data for local preview described in this blog is not an official feature! Hence, there is no guarantee that it will always work like this. If you face any problems with it, you can't ask SAP support for help. However, you can ask questions here, and I'll be happy to answer them.
Supported Objects
With the procedure described in this blog, you can extract data for most of the objects that SAP Sales/Service Cloud Version 2 offers PDF generation for. The following table gives an overview of the objects and shows where the procedure is applicable. For Leads and Surveys the procedure is unfortunately not applicable as those use a different technique to generate the PDF. However, there are alternatives that can help you even with those objects. I've included more details on this below.
| Object | Procedure applicable |
| Appointment | Yes |
| Case | Yes |
| Lead | No |
| Registered Product | Yes |
| Sales Quote | Yes |
| Survey | No |
Tools - Prerequisites
To carry out all necessary steps, we need a special toolset with capabilities to decode Base64 text and convert JSON to XML. If you don't do such things every day and have the right tool for that already installed, this might be a first challenge. When searching the internet for suitable solutions, you might quickly find some free online services that offer their help and, thankfully take the data you provide...
I highly encourage you to never use any kind of free or publicly available online services for such kinds of tasks due to data protection and privacy reasons! I'm sure several tools out there can do the job. In this guide, I use Visual Studio Code in combination with two plugins:
- For decoding Base64, we can use the Mime Tools plugin: ajogyashree.mimeconvertor
- For converting JSON to XML, we can use the convert json, yaml, xml, and others plugin: petli-full.json-to-yaml-and-more
Visual Studio Code is free and available for all common platforms. The mentioned plugins are published under the MIT license, and their source code can be found on Git Hub. A much better alternative to online services 💪
Procedure
Log in to SAP Sales/Service Cloud Version 2 with your browser and navigate to the screen where you can open the preview or generate the summary of the desired document. I use the Sales Quote as an example here.
Open your browser's Developer Tools and activate the Network tab. In most browsers they look very similar and offer the same feature set. Depending on your browser, some elements might have a different caption. The screenshots of this blog were created using the Windows version of Google Chrome. In many browsers you can also access the developer tools by pressing [F12] or the key combination [Ctrl]+[Shift]+[ i ].
In Chrome, there are two buttons on the very left (A) that allow you to start and stop recording network activities and clear the log in case you have recorded too much and want to start over again. Make sure the recording is active while carrying out the next step.
In SAP Sales/Service Cloud Version 2, you can now hit the button to open the preview (or in other objects: generate the summary). On the Sales Quote screen, we can find the Preview (1) button in the three dots menu (or one screen earlier on the work list):
After opening the preview, you'll see an entry in the network monitor that points to /sap/c4c/api/v1/output-management-service/template/renderForm (2). This call triggers the PDF generation and luckily, it reveals the data that's handed over to the Adobe Document Services/Forms Service by Adobe that are used in the background. Select the entry and activate the Payload tab (3). The request payload consists of JSON data. The field businessJsonData (4) contains the actual document data in JSON format, encoded as Base64. We can already see the light at the end of the tunnel! But we still have some work to do: We still have to decode the Base64 string and convert the resulting JSON to XML.
This is where Visual Studio Code and the mentioned plugins come into play or your favorite tool that can do these tasks.
Copy the Base64 to an empty Visual Studio Code text file. Pay attention that you copy the whole Base64 string as the browser may only show the beginning of the lengthy text. Possibly there, is a separate [Copy] button next to it, as seen in the screenshot above (4). In case the copied text starts or ends with quotes ( " ), remove them.
Then, it's time to use the first plugin: Mime Tools. Make sure the whole Base64 text is selected ( [Ctrl]+[A] ), and open the command palette (with default settings [F1] or [Ctrl]+[Shift]+[P] ), and search for "Mime Tools: Base 64 Decode".
Format the JSON by choosing Format Document from the context menu and scroll down to the end of the file. Make sure the JSON structure is valid, i.e., all brackets are closed correctly and that there is no additional content behind the last closing bracket. This can happen if you didn't copy the whole Base64 string or had other characters selected when decoding.
Then, we use the second plugin to convert the JSON content to XML. Open the command palette once more and search for JSON, YAML, XML and more. After selecting it, you have to enter the source and the target format in a second prompt. Enter "json | xml" (without the quotes) and wait a moment. The plugin will automatically create the XML representation of the JSON file in a new document tab.
The final step is to replace the root element <root> and the XML declaration with the one for Adobe form templates:
<?xml version="1.0" encoding="UTF-8"?>
<xfa:data xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/">
<data>
...
</data>
</xfa:data>
The following screenshot shows the XML before (left) and after (right):
After replacing the root element, you have the final sample data XML that you can load into the Adobe LiveCycle Designer for local preview.
That's it!
At first, this procedure might seem a bit complex and cumbersome. But it's worth the effort! The good news is: You can do it whenever you need it without opening a support ticket and waiting for an answer, or uploading a special template, which might not be possible in a productive environment, etc.
Alternatives
As mentioned earlier, the procedure explained here doesn't work for all objects. Luckily, there are workarounds for the remaining objects.
REST API
SAP Sales/Service Cloud Version 2 heavily relies on REST APIs, which are also used to load object data on the web frontend. You can see this in the Developer Tools' Network monitor. As far as I figured out, the structure (not the whole content!) returned by the REST API services, is compatible with the form template sample data. Example: A lead contains the node "account" which in turn contains the node "address" with the corresponding fields respectively.
That means, when opening a lead in SAP Sales/Service Cloud Version 2, the Network monitor will show a call to the service /sap/c4c/api/v1/lead-service/leads/<UUID> that returns the lead data as JSON.
This JSON can be converted to XML, and after replacing the root element, it can technically be used as XML sample data.
Keep in mind that this is not exactly the same JSON/XML
that the system would use to generate the PDF.
When comparing the data from the REST API response with the data that was actually used for generating the lead summary, I found out that there are differences. In my test, the REST API was missing the field accountContactsStatusDescription, for instance. With other sample data, other fields could be missing or containing slightly different values. If the data contained currency fields, they occur with a different number formatting in the REST API response, while the actual output data takes care of things like formatting of decimal places.
You can use the REST API approach for other objects as well. Depending on the object, the differences might have a smaller or bigger impact on the result.
Conclusion: While the data of the REST API might serve as valid XML sample data from the structural point of view, it might still differ. Hence, you cannot rely on this approach for the entire design and testing process, at least not without knowing the differences and where to pay attention to. However, knowing these differences can still help you quickly get sample data even if it is out of productive systems.
If you would like to know how the actual structure looks, you should read the section about the Debug Sheet below.
REST API - Special Case: Sales Quote
The Sales Quote service offers an interesting parameter to get closer to the actual output data, at least from the perspective of the fields contained. If you look closely at the screenshot of the Sales Quote Preview call, you will notice another request before the renderForm one:
4bd6c4c2-cfa4-44ef-8290-ae7b7b483d8c?$forOutput=true
Comparing the call responses with and without this parameter showed at least differences in the priceElements structure in my tests. But even the "forOutput call" didn't have the correct number formattings for currencies. Therefore, my conclusion for this alternative is as follows:
Conclusion: I suggest still using the initially described procedure using data from the renderForm call to avoid formatting issues. Furthermore, this alternative seems to be available for sales quotes only. Hence it doesn't apply to other objects anyways. (Calling other services with this parameter didn't change their response in my tests.)
Debug Sheet - Get the XML data with a special form template
If nothing else works, you can still upload a special template that displays the actual XML data handed over from the system as text in the PDF. For that, you can use my "Debug Sheet", which I created some time ago. It's a minimalistic template that focuses on extracting the data XML and making "copy and paste" from the PDF as easy as possible (the small font size shall help to decrease the number of page and line breaks).
You can download the "Debug Sheet 2" here.
In contrast to version 1, which used a special script to read and display the XML, version 2 uses the built-in function xfa.data.saveXML("pretty"); .
To use it when generating a PDF, you have to upload it as a custom template and assign it in the Form Template Selection.
While the Debug Sheet gives you the best insights into the XML data with the finally available fields and number formattings, copying the XML out of the PDF is error-prone. And before you can use it, you have to upload the form template first, which is usually okay in a test environment, but often problematic if you need to get data from a productive system, for instance, when the currently uploaded form template has some issues.
Conclusion: Use the Debug Sheet in test environments where the renderForm procedure can't be used. This ensures the best result in this situation. As long as you are aware of the differences to the REST API, you can consider switching between these methods depending on the use case.
Final Conclusion
For SAP Sales and Service Cloud Version 2, you should use the renderForm procedure whenever possible to extract data for local preview from the system. If this approach is not applicable (Leads and Surveys), you should use the DebugSheet to get sample data. If this alternative is not possible, for instance, because someone discovered an issue with the currently uploaded Lead form template in a productive system and you need to extract data right from there. However, keep in mind that the root cause could exactly be the difference between REST API and actual output data. So, you should know the differences when using the REST API(s).
Live Sessions
I deliver monthly live sessions with a changing agenda on print form adaptation. If you are interested and would like to join, you can find the details as follows:
Starting in 2024, the live sessions have moved to a new platform: You can find them via this new direct link on learning.sap.com. (You still need a corresponding subscription in order to register for the live session.)
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
