Scenario 1: Your application is running on an on-premise ABAP or Java backend
On your local hardware, you basically have all the standard components you need to communicate over the internet with SAP BTP, like the SAP (ABAP) system with its communication layers (ICF, RFC) and the SAP Cloud Connector (to be downloaded and installed as an additional component). Then, of course, there are the tools you need for the actual form processing within your system, like the form processing framework, the form processing repository, the spool service (for printing), and the application that’s using SAP Forms by Adobe.
All the rest is hosted by SAP: the ADS component, a configuration UI (that you can access with your Web browser), and the required communication interfaces.
Scenario 2: Your application is not running on premise (for example, on SAP BTP)
In this case, your application can call the SAP Forms by Adobe REST API. It provides a subset of the already known ABAP PDF Object features. They are addressed by different URIs (Uniform Resource Identifiers) where each URI supports data and document exchange in a JSON format. The SAP Forms by Adobe REST API delivers a comprehensive description and is easy to test. Similar to the first use case, the application calls the REST API via an SAP BTP subaccount that must be subscribed to SAP Forms by Adobe.
Here’s an overview of the scenarios currently available :
Now, knowing how it all works together, your next question (and possibly the most critical) might be: What do I need to do to make it work?
Well, not a lot, and the best thing is: you only have to do it once. SAP does all the rest for you.