Import of a nugg
Closed this issue · 17 comments
Hello Łukasz,
Which saplink plugin for function group do you suggest to use? It seems that a plugin from saplink plugins daily nugget ( https://www.assembla.com/spaces/saplink-plugins/wiki ) has an issue with importing of CUA of the ZFALV function group.
Hello Andrei,
I think I used the daily build from https://www.assembla.com/spaces/saplink-plugins/subversion/source/HEAD/build, and I had no problem with importing on two systems already. But I will check in the evening.
Cheers
Łukasz
I did the same. And here are two issues I've faced:
- First of all xadm structure is always empty. As a result, there is a check in RS_CUA_INTERNAL_WRITE in the very first check_adm call which will not pass because it's only skipped if: if not l_adm is initial. return. endif.
- Second issue is a consequence of empty xadm and the fact that xtrkey-obj_type passed as PROG in the same FM. In trdir SAPLZFALV program is defined as F (function group) but passed to this FM as PROG and check:
elseif l_subc = 'F' and tr_key-obj_type = 'PROG'.
message e651(EU) with 'tr_key-obj_type = PROG' raising invalid_data. return.
will raise an error. Dirty trick would be to set sy-tcode to SE41 before RS_CUA_INTERNAL_WRITE call.
In general, these issues are not directly related to your great project. But it might stop someone to import a nugg into a system because it won't run smoothly. Of course, we're all developers and can adjust some staff in debugging to overcome these issues, but anyway...
I cannot find the check you have mentions, in which include it is and in which line? Maybe we have two different versions of RS_CUA_INTERNAL_WRITE ?
Seems like I have the latest version of the daily build of ZSAPLINK plugins.I've downloaded for sure the latest one and most probably I've used it.
Mentioned checks are in the very beginning of RS_CUA_INTERNAL_WRITE in my system (NW 740 SP13). Seems that they were brought into this FM recently. Surrounded with asterisks and commen "* prevent writing inconsistent data by UDO". Lines from 46 to 90. Starting from 92 there is good old
if state = space. state = scua_c_state_active. endif.
I found an OSS note which introduces these changes in 740 SP12. 2159455 - MenuPainter: New consistency checks due to downports (UDO)
There is even SAPLink mentioned in it as one of the reasons :D
I was not working so far with NW younger than 740 SP08, but let's point it to SAPlink developers :-)
It's already pointed by @se38 under https://www.assembla.com/spaces/saplink/tickets/276-dump-during-import-pfstatus-in-nw-7-50-/details. I will add there comment about 740 SP12 also.
Hey,
i had the same problem while trying to get the newest version of the abap2xlsx nugget in our system. As Suhas Saha mentioned in the SAPlink User Documentation (https://wiki.scn.sap.com/wiki/display/ABAP/SAPlink+User+Documentation), if you change all pfstatus_men, pfstatus_act and pfstatus_pfk from pure numeric (e.g., 000001) to alphanumeric (e.g., Z00001), it will process with no errors.
However i'm really unsure if this is a valid workaround as i have to test first, if the imported classes and reports will still work.
Seems they are working correctly, but manual adjustment of the nugget is not the best way. I'd prefer the dirty trick of Andrei.
Dirty trick would be to set sy-tcode to SE41 before RS_CUA_INTERNAL_WRITE call.
Well i can confirm that Andreis solution is the better one. The GUI Status in my reports are completely destroyed and im currently searching for a way to get a good one imported in my system.
Update:
Just for the reason, that this thread is one of the top google results if you search this error i'm gonna leave my solution here to get the correct GUI status imported:
With Notepad++ you can open the provided .nugg file and search for the report that has the GUI Status. For example:
<PROG NAME="ZDEMO_EXCEL41
I copied the whole report (PROG) section + the outer section (<?xml and <nugget) of the XML describtion of the .nugg file into a new file and saved it as another .nugg file.
<?xml version="1.0" encoding="utf-8"?>
<nugget name="C:\Projects\SAPlink\trunk\build\SAPlink_Daily.nugg">
<PROG NAME="ZDEMO_EXCEL41"
..
</PROG>
</nugget>
This .nugg file can be imported with the debugging changes Andrei suggested (clear L_NOK and set SY-TCODE to SE41), but before you do this, delete the old version of the report in your SAP target system. Otherwise you might get inconsistency errors which can't be fixed with the method i'm providing in the following.
Once you imported your homemade .nugg file (and with that, the chosen report with the GUI status) you can activated the whole report in SE80 and it will run perfectly. If you try to open and edit the imported GUI status however, you will also get an error because of inconsistency issues.
This can easily be fixed if you just create another GUI status (just skip the error message, add a name and desription and save + activate it). After this step, you should also be able to edit the imported GUI status with no inconsistency issues displayed.
It might be a good time to switch to abapGit https://github.com/larshp/abapGit. @fidley, what do you think?
I want to give a try to abapGit but this will not solve the problem for importing, as everyone would need to fork a project if they'd like to use FALV. Or maybe I have missed something?
What is the reason to fork? It's just the same as SAPLink, but pay attention for a goal of abapGit as well relating to git hub and human readable format. Also I plan to fix this issue with CUA next week after my vacation. BTW, Gregor Wolf named it as a successor of SAPLink during last #sitMUC. Proof: https://twitter.com/cyclingfisch/status/652836135803219969
I thought that you need to fork the repository in order to use it, if not then maybe I'll switch faster to abapGit ;) I must look on this shortly!
You need to fork if you want to contribute a pull request, just for that. In other words, create one single report in the system, copy & paste and you are good to go.
PS: CUA issue is not fixed yet ;) And I know one more place there with a small issue. But to be fixed anyway very soon.
Seems that SAPlink issue is fixed by Stefan Schmöcker:
https://app.assembla.com/spaces/saplink/tickets/276-dump-during-import-pfstatus-in-nw-7-50-/details
, but I have no chance to test it.