Winshuttle launched new product offerings at Sapphire in 2010 that have the potential to revolutionize the thinking around form development for SAP environments. One of the features demonstrated there and at SAP insider conferences and ASUG meetings subsequent, has been how easy it is to build Adobe forms around SAP content but how different is this to Adobe and SAP’s own approach to forms?
The answer is, quite different! Adobe Interactive Forms for use with SAP and Winshuttle’s approach to leveraging the PDF file format standard are quite different on a number of fundamental levels.
While both approaches leverage the use of Adobe’s proprietary PDF format for the document template, the reality is that Winshuttle’s approach to interfacing with SAP doesn’t involve any customization or enhancement to the SAP environment itself. Additionally, there are no prerequisites for support packages or ABAP components on the SAP environment. Enterprise services do not need to be activated and there are almost no changes required to the SAP security model.
More importantly, there are very few limitations in terms of functional areas to which the Winshuttle approach to forms design can be applied. Perhaps of even more interest, is the fact that the Winshuttle approach to providing interactive forms, is actually not limited to Adobe’s PDF file format you can actually use Microsoft’s InfoPath product, Winshuttle’s own HTML Forms product or in fact any environment that understands and can leverage web services.
Some other factors that make the Winshuttle approach fundamentally different is the fact that you can leverage the same methods that you have perhaps historically used for creating LSMW and BDC sessions to create and change data in your SAP systems except that now you feed that data via a form based environment rather than from a text file.
Building Adobe forms with WInshuttle’s approach does require just as much skill in sensible form design as the SAP/Adobe approach to form design and requires the same level of design diligence around in-form field validation, formatting, font and visual element selection however the accessibility of the web service definition language objects (WSDLs) that support the form’s function are fundamentally more straightforward and require infinitely less skills to be easily consumed by intranet and extranet communities.
While Adobe Interactive Form design for SAP environments often involves a small army of multi-skilled indivduals including ABAPers, BASIS resources, functional and technical analysts and Adobe form designers, the Winshuttle approach requires much less in terms of resources.
Most implementations can be undertaken with just one or two resources. Namely a functional analyst familiar with the specifics of a given SAP transaction and a familiarity with Winshuttle’s Transaction recording product suite and a resource familiar with Adobe Lifecycle Designer or whatever form design product you plan to use.
As you can already surmise, the approach with Winshuttle, is to produce a transaction recording as a webservice. For many form based scenarios this may be more than adequate for SAP transaction simplification with an application delivery lifecycle that spans hours or perhaps days rather than weeks or months.
Most time is found to be spent on form design and construction than on the actual creation of the underlying webservice(s).
The underlying Winshuttle infrastructure required to serve up the webservice additionally supports queries and the use of BAPIs and remotely enabled function modules so there are an array of options available.