Avoiding Sharepoint for Extracts and Source Data

SharePoint has been experiencing a growing market share in the field of cloud-based data management and is a fine solution for many distributed applications. SharePoint allows content to be distributed to people outside the corporate network, but when it comes to handling source data, network shares on the corporate network are the optimal solution because there is no need for manual steps between extracting, transformation and loading.

Adding an unnecessary manual step

When a legacy developer produces an extract, that data is not automatically loaded onto a SharePoint server. The data is first saved on a computer hard drive--most likely on the local developer's computer--and then manually uploaded to a SharePoint server.

Adding another unnecessary manual step

There is no way to read source data directly from a SharePoint server into SAP or into Access. Prior to importing the extracted data from a SharePoint server, a manual step to download the data file from the server to a local hard drive is required.

A cumbersome route from legacy to LSMW

By configuring the extract program to save the extracted data in the same place that LSMW is configured to read from, nearly all manual manipulations of the data can be avoided. Using the same UNC like \\server\share\source.txt in the extract program and the LSMW object ensures that the most recent extract is always the one that is loaded into SAP.

A clean route from legacy to LSMW

Not only are cumbersome, time-consuming manual upload and download steps eliminated, the chance for human error caused by faulty naming conventions is eliminated. Revision control is performed by backups instead of changing the name of the file or by uploading to a new directory.