Skip to end of metadata
Go to start of metadata

Everyone knows that the first time you install SAPlink, you have to run the ZSAPLINK_INSTALLER program.  The reason for this program is obvious, but it wasn't a straight forward decision. When we first designed SAPlink, we asked ourselves how annoying would it be to install SAPlink manually, especially since this was the very problem that is was supposed to solve.  At one point, we adopted the phrase, "SAPlink, the last manual install you will ever need".  In the end, we found this unacceptable, and the adventure began to come up with an easy way to install.  The recursive nature of the conversations that ensued were enough to make your head spin.  We need SAPlink to install SAPlink, etc., etc.  We decided that the easiest way to do this was to have a flat Z program that would have all the basic components of the SAPlink core and plugins needed that would be just enough to get the base install on a system.  This worked for a bit, but going against the DRY (do not repeat yourself) principle, proved a huge pain, especially during the initial releases of SAPlink where the core plugins (mainly classes), were not stable.  We found many instances where we would fix a major bug in the CLASS plugin class, only to realize that we still had the same error in the installer program.  Sometimes we did not catch these because we were upgrading our own versions of SAPlink, with SAPlink.  We found the need to do clean installs to test.
This was fine for a small time, but as we were refactoring, we went on a mission to solve this duplication of code.  What we came up with was a SAPlink utility called the Steamroller.  The Steamroller is basically an app and a class that takes program A that has global class calls and converts it to program B that turns all global class calls to local class calls.  This is where the recursive discussions really became interesting.  So in a nutshell, if you are upgrading core classes on your SAPlink development system and you want these changes to be included in a new installer program to be released, you need only to run the steamroller app, and it will use a template installer program that has global class calls, and turn it into one huge, flat installer program with all local class calls.  The global to local conversion only happens on the application level, so if there are global class calls inside of your global classes, these will remain global class calls.
The steamroller app, the tools class, and the installer template can all be found in the trunk of the repository:

You have to start the ZSAPLINK_STEAMROLLER report using the parameters shown in the next screen shot:

It will create a new version of the ZSAPLINK_INSTALLER based on the ZSAPLINK_INSTALLER_TEMPLATE. In this process the steamroller will convert the global classes to local classes.

1 Comment

  1. Former Member

    Are there plugins available for VDAT, TDAT objects which can help to transfer such objects from one system to the other?

    Thanks... Balaji