When should I use Winshuttle Transaction to create a ‘report’ versus Winshuttle Query?
By Clinton Jones on Apr 5, 2011
In response to a number of questions that have come up recently regarding the capabilities of reporting with Transaction versus Query, I thought I would share these with you by way of a blog post.
Winshuttle offers three methods of extracting and reporting data from your SAP system:
The first and most preferred method is through the use of Winshuttle Query, a desktop query building application that allows you to join ERP tables, Infosets, and logical databases together in a way that enables you to extract ERP data (including custom fields and tables). This data can be furnished to the organization in targets that include Microsoft Excel, Microsoft Access, Microsoft SQL databases, and other formats. Additionally, these queries can be published as web services to be consumed at the enterprise level by other applications including SharePoint, PDF’s, InfoPath forms and Winshuttle Forms. Winshuttle Query allows the choice of target system based on a product licensing model. Query is a straightforward replacement to SE16, SQVI, SQ01 with more checks and balances, better performance, and enhanced security. You can learn more about the specifics of the product at https://www.winshuttle.com/Products/Winshuttle-Query Query
Query does allow some basic transformations of your extracted data; however, dashboards and pivot tables would have to be built into Excel itself or whatever the output format is chosen from the extracted raw data. You can leverage pre-built templates in Excel containing the pivot tables and macros as you see fit and then refresh the data by way of the Query download.
Transactions set to read mode
The second approach would involve the use of the Winshuttle Transaction product. This approach requires you to create a recording of a given transaction, typically a read transaction like VA03, MM03 or FB03 (including custom and Z) .
However, you are not restricted to just these read transactions, you can also use some create and some edit transactions to create ‘read’ recordings. This approach is less efficient than a query, requires potentially more SAP security effort for exposure to a wider audience, and more importantly, uses record keys or ID’s rather than selection criteria to extract data.
Typically Winshuttle customers only use this approach when queries would be extraordinarily complex or where the data to be reported is contained in an SAP structure rather than in a table or collection of tables. This read transaction recording can have Microsoft Excel or Microsoft Access as a source and target for the data.
When used in conjunction with Winshuttle Central with Winshuttle Server it can be used to create web services that can be consumed by other technologies including SharePoint, PDF’s, InfoPath forms and Winshuttle Forms.
Winshuttle Transaction is a straightforward replacement for LSMW and BDC sessions with more capabilities and a better overall design, implementation and user experience. Scripts created with Winshuttle Transaction can be ported across multiple SAP systems provided that they have common configuration attributes for the given transaction.
Leveraging BAPIs and RFMs for Reporting
The third approach is very similar to the second except it introduces another product, Winshuttle Direct. Winshuttle Direct can only be used together with Transaction to create data extractions. Direct also allows you to select and enable Remote enabled Function Modules – RFMs (including custom and Z) and BAPIs to be used within Winshuttle Transaction in the same way that you would use a transaction based recording.
The advantage of using Direct with Transaction for RFMs and BAPIs is that this method of data extraction is typically very efficient and does not suffer from the complexities of joining tables or defining selection criteria. Additionally, it is a more robust approach when compared with a read enabled transaction recording, and generally does not suffer from the quirks of unexpected popups and artifacts associated with using the flow logic of Dynpros.
Unfortunately, RFMs and BAPIs do not exist for all functional areas in SAP and again, often input criteria such as document numbers, vendor, customer or material numbers are required to make these work.
Scripts created with this method can be used in conjunction with Winshuttle Central and Server to create web services that can be consumed by other technologies including SharePoint, PDF’s, InfoPath forms, and Winshuttle Forms.
Transaction with Direct templates are a straightforward replacement for LSMW and BDC sessions with more capabilities and a better overall design, implementation, and user experience. Scripts created using Winshuttle Direct with Transaction can be ported across multiple SAP systems provided that they have common SAP configuration and versions, BAPIs and RFMs are set from the date of release, and are not generally edited between SAP releases. Historically, the approach has been to release alternate RFMs and BAPIs with new capabilities.
Be warned that some RFMs and BAPIs are not considered ‘released’ for general use – the functionality may be less than the capability of a supposedly equivalent enhanced SAP transaction and RFMs and BAPIs are notoriously poorly documented. Be prepared to have your thinking cap on and a willingness to do a lot of searching through SAP notes and SCN Wikis, forums, and blogs.
About the author
The Winshuttle blog is written by professional thought leaders who are dedicated to providing content on a variety of topics, including industry news, best practices, software updates, continued education, tips and techniques, and much more.
Questions or comments about this article?
Tweet @Winshuttle to continue the conversation!