#277
- Created on2016-01-07 22:09
- Reported by
- StatusAccepted
- PriorityHigh (2)
- Assigned to
- Milestone-
- Plan Level-
- Due Date-
Method Redefinitions are not imported
Redefinition statements, regardless whether they are part of the Slinkees and Nuggets, are not imported into the target class.
This may also explain, why during the SAPlink installation the required methods are not redefined.
This may also explain, why during the SAPlink installation the required methods are not redefined.
Leave a comment
on 2016-07-03 08:02 *
By Stefan Schmöcker
on 2016-07-03 08:03 *
By Stefan Schmöcker
Assigned to set to Stefan Schmöcker
Status changed from New to Invalid
on 2016-07-03 08:39 *
By Stefan Schmöcker
Actually the redefinition statements are imported - but R/3 sometimes gives an errormessage for the implementation of an abstract class that the class has to be redefined before it can be implemented.
For example in the current DailyBuild-Nugget the installation fails for the class ZSAPLINK_CLASS complaining about method CHECK_EXISTS but works for the class ZSAPLINK_PROGRAM but both classes have redefined and implemented the method CHECK_EXISTS.
The reason for this is the order in which SAPlink imports the objects in a nugget. The classes in the current daily build are in alphabetical order, and thus the sequence of installing is
ZSAPLINK_CLASS and ZSAPLINK_PROGRAM are both inherited from ZSAPLINK_OO, but ZSAPLINK_CLASS gets imported before the parent class ZSAPLINK_OO and ZSAPLINK_REPORT gets imported after ZSAPLINK_OO.
This also explains the workaround that states that to have it all work out you have to run the ZSAPLINK_INSTALLER twice because now every class gets overwritten by itself but since the first run ZSAPLINK_OO is known in the dictionary and now the second import of ZSAPLINK_CLASS finds its parent and thus does not throw the error any more.
As a workaround I changed the daily-build nugget and moved the ZSAPLINK_CLASS part to the end of the nugget and tried to import on a new system and it works out fine.
Could anyone crosscheck whether the new daily build imports directly in their system.
Be aware though that this is only a fix for the installation of SAPlink - the basic problem of the installation order in SAPlink still remains and I am still thinking of a solution.
For example in the current DailyBuild-Nugget the installation fails for the class ZSAPLINK_CLASS complaining about method CHECK_EXISTS but works for the class ZSAPLINK_PROGRAM but both classes have redefined and implemented the method CHECK_EXISTS.
The reason for this is the order in which SAPlink imports the objects in a nugget. The classes in the current daily build are in alphabetical order, and thus the sequence of installing is
- ZCX_SAPLINK
- ZSAPLINK
- ZSAPLINK_CLASS
- ZSAPLINK_NUGGET
- ZSAPLINK_OO
- ZSAPLINK_PROGRAM
ZSAPLINK_CLASS and ZSAPLINK_PROGRAM are both inherited from ZSAPLINK_OO, but ZSAPLINK_CLASS gets imported before the parent class ZSAPLINK_OO and ZSAPLINK_REPORT gets imported after ZSAPLINK_OO.
This also explains the workaround that states that to have it all work out you have to run the ZSAPLINK_INSTALLER twice because now every class gets overwritten by itself but since the first run ZSAPLINK_OO is known in the dictionary and now the second import of ZSAPLINK_CLASS finds its parent and thus does not throw the error any more.
As a workaround I changed the daily-build nugget and moved the ZSAPLINK_CLASS part to the end of the nugget and tried to import on a new system and it works out fine.
Could anyone crosscheck whether the new daily build imports directly in their system.
Be aware though that this is only a fix for the installation of SAPlink - the basic problem of the installation order in SAPlink still remains and I am still thinking of a solution.