As we are more and more involved with Adobe products integrated with SAP solutions, we get lots of demands and questions from customers and partners regarding scenarios.
The SAP Interactive Forms by Adobe are an excellent and powerful tool, integrated in all SAP solutions as of NetWeaver04 (ERP2004). The online scenarios are well known: integration with Web Dynpro (ABAP and Java), with ISR (Internal Service Request) as well as with various other SAP modules (ECC, CRM, SRM etc.) By the way, you can download here all the available Interactive Forms in SAP solutions.
As a de-facto standard for document exchange, the PDF is very often sent independently via a regular mail. You can now automatically send an invoice, a purchaser order to external parties (suppliers, customers). Data can then be processed by some people, or some backend.
Now, what if we want to use the PDF as a data input screen in offline mode? For instance, let’s say you want to send a purchase requisition, which must be filled by some user, and then sent back to your system?
This scenario offers a lot of advantages for the external user:
- He doesn’t need an SAP user;
- He most likely already knows PDF and has Adobe Reader, so no training time is required;
- He enters data without errors, thanks to error correction scripting you’ve integrated in the interactive PDF; so he saves time;
- He can save locally what he sent you, print it, archive it etc.;
For you, there are also numerous advantages:
- You don’t need an application to embed the form, so no additional servers are required;
- You don’t need to re-enter data sent via paper or mail.
Okay, but what are the possibilities do realize this? Let’s have a closer look.
Web service call
An interactive form can, in standalone, make a call to some web service. And as you may know, in the NetWeaver versions of SAP systems, every remote-enabled function module can be exposed as a web service!
The web service call logic is embedded in the Interactive Form you sent to your customer. When he clicks on ‘Submit’;, the web service is called, and your SAP backend is updated. Great!
Of course, for this you need some coding. First, in the PDF: let’s imagine a user clicks, for some reason, 7 times on the submit button. It doesn’t mean he wants to order seven times the same amount of material! Also, there must be some kind of authentication in the form, and maybe security features…
Secondly, in your backend, to handle the errors and to manage the data processing. In one word, to store those data in the appropriate tables. This is a part of your business logic, which must be in every case present in your SAP backend.
Regular mail pt.1: XML data parsing
In the sent interactive form, you can embed a predefined email address, where data will be sent in XML format. In your PDF, the data are stored in a structured XML format and can be automatically extracted and copied in attachment in a mail (using the mail client).
At your backend side, you have to expose this email address and code the XML parsing as well as the business logic.
To avoid the annoying XML parsing part, one solution is to use XI (SAP Exchange Infrastructure). There, you define an email address, an interface and you map the received data to some function module handling the logic.
Of course, this depends on your landscape, and also on your developers’ skills.
Regular mail pt.2: PDF display
For very simple workflows, you can choose to send via mail the full PDF containing the data.
Here at SAP Belgium, we’re planning to implement this possibility for the two well-known travel request and training request scenarios. In this case, I fill in my travel request, click on submit and the whole PDF is sent to my manager, who can approve or reject my request. He then clicks on submit and the PDF is sent to me (so I can check if I’m allowed to go to some exotic place for business) and to our dear travel coordinator (who books a flight and the hotel).
An SAP backend can also extract the XML data directly from a PDF, with the help of the PDFObject API. So you can send the same form simultaneously to one human and to your system.
This scenario is already available in the Web Dynpro for Java tutorials section. This tutorial can be downloaded here.
In this case, your external user uploads his filled form into a Web Dynpro application, can eventually revise entered data, which are then processed by the application to your backend.