Remote-Check does not work

[StefanRiedel-Seifert]

The Codepal check seems to be remote-enabled, I have setup them in our Remote-CI-Hub, but the checks are not triggered: always passed without error, which is not correct. On the local system, they work and the installation local and remote are absolutely identical. I get no dumps on the remote system.

[estevao-schultz-neto-SAP]

The attribute: = ABAP_TRUE is set directly in the constructor of the Y_CHECK_BASE (all CHECKS inherit from this class). We thought the CI Framework would take care of the rest. Now, checking if there is still something else needed.

[StefanRiedel-Seifert]

Checked the documentation:

• REMOTE_ENABLED allows to check with an outdated scenario (which uses a push approach rather than a pull approach by manually uploading the extracted source code to be checked). If your check is based CL_CI_TEST_ABAP_COMP_PROCS and is the flag REMORE_RFC_ENABLED is set to ABAP_TRUE, you can also set REMOTE_ENABLED to ABAP_TRUE.

• REMOTE_RFC_ENABLED indicates that your check can be carried out remotely. Note that it is your responsibility to ensure that your check can run remotely if you set these attributes as true – the attributes themselves are merely of an organizational nature and do not enable your test to run remotely! Additionally, beware that these attributes might be inherited from the superclass if you do not set them yourself, even if the classification does not apply to your check.

[lucasborin]

Is the code under inspection available in the remote system that will perform the inspection too?

[StefanRiedel-Seifert]

… no. That's the nature of an remote hub.

[estevao-schultz-neto-SAP]

Both flags are set actually: REMOTE_ENABLED and REMOTE_RFC_ENABLED. We are checking...

[lucasborin]

I tested here, and it works.

However, you must have:

• the code pal installed and active in both systems
• RFC set in SCI => Code Inspector => Management of => Remote System
• Remote Check Variant created in SCI => Check Variant => In Remote System => Y_CODE_PAL (or, your variant)

It looks like this feature will read the variant from the remote system only. I mean, it won't execute the Check in the remote system, but so locally with the 'remote variant' customizing.

If you have it all, I recommend you to check if an authorization is missing in the target system for the user set in the RFC. (you can use the t.code SU53).

[StefanRiedel-Seifert]

I have a working system environment, that means:

No auth problems Working destinations

I have code pal installed in both systems.

I have code pal activated (full blown) in remote variant

Locally: findings, remote: nothing

[estevao-schultz-neto-SAP]

For me, it does not make sense that the CHECKS have to be in the target system. But... Our colleague Thomas Fiedler has offered help and we can contact him on this matter. @lucasborin Will you please Lucas?

[estevao-schultz-neto-SAP]

@StefanRiedel-Seifert: Why did you close the issue? Could you reopen as it is not yet solved? We are on it.

[StefanRiedel-Seifert]

oh, may be a mistake from myside :-(

[StefanRiedel-Seifert]

... accidentally closed

[estevao-schultz-neto-SAP]

We are analyzing this carefully and will reply to you soon.

[mihabosa]

Is there any update on this issue? We also want to use the code-pal checks via RFC from a central check system.

[lucasborin]

Unfortunately, code pal only works in the system which has the object under scan as it consumes local tables like TRDIR, TADIR, REPOSRC, etc. These tables are required for code pal specific features like object automatic exemption, object creation date determination, the distinction between productive and test code, etc. Therefore, this feature is not available yet.

To enable it, we have to change these database reads by a function module with RFC enabled.

[ThomasErgin]

I want to implement a central ATC server, too and would also love to see the Code Pal RFC enabled. For companies with a big number of development system this feature totally makes sense.

[lucasborin]

Hi colleagues. I created a draft version (2.00.0, #539) that supports the RFC scenario. Feel free to install it in your sandbox system (as it is an alpha/beta version) to test it, and provide your feedback. In short, it needs the authorization to call the function module RFC_READ_TABLE.

[DerGuteWolf]

Demanding authorization to call the function module RFC_READ_TABLE is not a so good idea as this opens severe security problems. Couldn't you provide your own FM reading also your tables?