In a migration datafiles are flying across systems. And the process of preparing the migration, these files are "being build" and have a tendancy of getting larger and larger. The receiving system will need to consume all this data, in multiple rounds. Here's the thing: receiving data that is already in the system because it was made available in earlier rounds, is a time (and resource) consuming matter.
Would you like to process changes only ? That can be arranged, with datafile information only. Read on...
These articles are about Interfacing in SAP. Interfacing between systems, or interfacing between standard SAP components and custom build components. A system without interfacing is a bit unreal: no information is fed into is and it feeds no information to other systems. Would it be missed ? Check out the Idoc articles on exchanging Idoc (Intermediate documents) between SAP and non-SAP systems In- and outbound. Check out the BAPI articles on access to documents bypassing a graphical user interface. And get to grips with the transport mechanism, which effectively interfaces development objects though the system landscape.
Where data in interfaced out of the system, there's always the discussion of full load and the delta loads, with advantages and disadvantages on both flavors. This article describes how to set up shadow checking in a way that I've implemented on 10+ serious interfaces to date.
Would you like to Start Word with template and data ? SAP can be linked to Office products using OLE, Object Link Enabling, which can be useful in a business situation. This article introduces a read-to-use and all standard SAP function module which allows you to start Word, pass data and open a Word template (.dotx) for the data. Use it to talk to Office Word in a preset way, or use it as a reference on how to interact with Office for other applications (Excel ?).
If you would like to trigger Excel or any other presentation server program, with parameters... There is a utility class available to help you, along with a few older function modules.
Are you downloading your own coding, to upload it again in another system ? If you are dealing with multiple customers, you must have your own suite of handy developments, like the ones you can find on AbapcadabrA.com. This too is a very handy ready to use mini application, that allows easy uploading and downloading Abap codng, including texts and menu's (titles). Dynpro's are downloaded as well, ready to be uploaded through the screen painter.
The data on SAP's tables sometimes needs to pulled out of the system. Compare to other systems, freeze the moment (repeat the download 2 days later and compare changes) or just to ensure nothing is lost when you are about to embark on something. This report is a download tool for data. It's quite flexible in letting you define which tables (multiple), which fields and which records. Table name and description, field names and table content of all tables specified will end up in a single dataset (file).
When linking to another system through webservices, it's not uncommon to create a service answering a request. Many types of request are possible here, from "get the name of a customer" to "give me the customer open orders" to "place an order". If the third party access is trusted, there's a way to make SAP database read access very easy. Consider creating a webservice for RFC function module RFC_READ_TABLE.
To compare tables, or rather table content in a landscape can be done through SAP's Customizing Cross-system viewer. Comparison can be done based on IMG activities, application components and also - very handy for developer-folk - via manual selection.
Use transaction OY19.
The interface toolbox is there for outbound interfaces about personell data, e.g. to an insurer. A toolbox was set up for this under transaction PU12. The interface toolbox evolves around transaction PU12. A variety of other PU12* transactions is available, but (nearly) all this functionality is bundled in the toolbox: PU12.