Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Is there an option to prevent ATC-checks dependent on PGMID and OBJECT?

BaerbelWinkler
Active Contributor

This is a follow-up question to the one I asked last week:

Can blocking of transport-release due to ATC-findings be circumvented for RS_LXE_LOG_EXPORT?

Since then, I also noticed that ATC-checks - if run for a transport directly - not just get triggered for PGMID=LANG with OBJECT=REPS/REPT but also for objects like Smartforms (PGMID=R3TR with OBJECT=SSFO). I don't think that it makes much sense to run the checks for objects like these, or am I missing something?

Is there already an option - or could there be one - to customize ATC in such a way to prevent ATC-checks from happening for certain combinations of PMGID and OBJECT?

Added: Ideally, this check would happen in the satellite-systems to prevent unnecessary RFC-calls via a trusted connection to the central-system.

Added Oct. 25: we've now had a couple of instances where colleagues without developer access couldn't release transports only containing a query-object (R3TR/AQQU) where ATC-checks don't make much sense either.

Thanks and Cheers

Bärbel

1 ACCEPTED SOLUTION

axel_jebens
Explorer

Hi Bärbel, hi Uwe,

Yes, I agree with Bärbel that it might be more consistent to exclude objects from the object set in all cases, not just transport checks. My initial idea was to focus on the transport check because you do not have the flexibility to control which objects are checked at all since the transport request cannot be filtered.

We could try to deliver a BAdI, and I have the impression that it would help you. If this is the case, please let me know, then we will evaluate whether it is possible to ship this.

22 REPLIES 22

Domi
Contributor
0 Kudos

Hi

Change the object set(s) of the used ATC-Check-Variant

If the standard options don't fit you can add more complex selections/restrictions with custom collectors,

see: https://blogs.sap.com/2012/08/23/code-inspector-custom-object-collectors/


regrards

Domi

BaerbelWinkler
Active Contributor
0 Kudos

dominik.bigl2

Thanks for the suggestion, Domi!

From what I see in the satellite system (NW 750 EHP8), there's however no option to mention an object set when using a check variant from a central ATC-system (NW 752). Only these fields are available to define the check-variant for "in reference check system":

Check Variant
RFC Destination
RFC System

And in the central ATC-system there also doesn't seem to be an option to tie/link a specific check variant with an object set (at least I don't see anything like that).

Wouldn't there need to be something like an optional field for "consider object set" where specific object-types could than be excluded via standard select-options?

Cheers

Bärbel

axel_jebens
Explorer
0 Kudos

Hi Bärbel,

This is another requirement to make transport checks configurable. Unfortunately, there is not yet any option to exclude object types. I will take a note of it, but I cannot promise that we will ship this very soon since our list of topics is very long.

Would it be sufficient to realize this via a Business Add-In (BAdI) to implement a filtering mechanism for the object list of the transport?

Regards,

Axel

0 Kudos

Hi Axel,

thanks for your reply.

I'm however not sure if this is really (just) a requirement for customizing of transport checks. Wouldn't it also make sense to have this kind of filter applied whenever an ATC-check is done, regardless of whether or not it happens during transport release or just ad hoc? This would then make it consistent regardless of why/when the check is done. I for example regularly trigger ATC-checks via report-programs either based on selection by reportname or transport (thanks to your response from 2 years ago!).

Cheers

Bärbel

Hi Axel,

any news on this? Currently I'm often getting exemption requests for BOR-Objects. Would be great to exclude these objects from the checks.

axel_jebens
Explorer

Hi Bärbel, hi Uwe,

Yes, I agree with Bärbel that it might be more consistent to exclude objects from the object set in all cases, not just transport checks. My initial idea was to focus on the transport check because you do not have the flexibility to control which objects are checked at all since the transport request cannot be filtered.

We could try to deliver a BAdI, and I have the impression that it would help you. If this is the case, please let me know, then we will evaluate whether it is possible to ship this.

0 Kudos

axel.jebens

Hi Axel,

yes, I think that a BAdI would help if there's a central place where it could be "plugged in" and if we then have the option to e.g. provide excluded combinations of PGMID and OBJECT via our own logic based on (Z-)table entries.

Thanks much and cheers

Baerbel

Until the ATC team is providing a solution, I've implemented an implicit enhancement in the central system at the beginning of method CL_CI_TESTS->RUN:

ENHANCEMENT 1  ZATC_EI_NO_CHECK.    "active version
  IF NEW zcl_atc_enhancements( )->is_object_to_be_checked(
                                    i_object_type = p_object_type
                                    i_object_name = p_object_name
                                    i_src_destination = me->src_destination
                                  ) = abap_false.
    RETURN.
  ENDIF.
ENDENHANCEMENT.<br>

And the check method is growing 😉

  METHOD is_object_to_be_checked.

    CONSTANTS lc_type_smartform TYPE sci_typid VALUE 'SSFO'.
    CONSTANTS lc_type_program TYPE sci_typid VALUE 'PROG'.
    CONSTANTS lc_type_class TYPE sci_typid VALUE 'CLAS'.
    CONSTANTS lc_sap_namespace TYPE sobj_name  VALUE 'ZSAP'.
    CONSTANTS lc_exception_class TYPE sobj_name  VALUE 'ZCX'.

    r_result = abap_true.

    "*--- Objekte, die nicht mit ATC geprüft werden müssen ---*
    "Smartforms
    IF i_object_type = lc_type_smartform.
      CLEAR r_result.
      RETURN.
    ENDIF.

    "BOR Objekte
    IF is_bor_object( i_object_name = i_object_name i_src_destination = i_src_destination ).
      CLEAR r_result.
      RETURN.
    ENDIF.

    "Reparaturprogramme auf Grund von SAP Hinweisen
    IF i_object_name(4) = lc_sap_namespace
    AND i_object_type = lc_type_program.
      CLEAR r_result.
      RETURN.
    ENDIF.

    "Tabellenpflegeview
    IF is_table_view( i_object_type = i_object_type i_object_name = i_object_name i_src_destination = i_src_destination ).
      CLEAR r_result.
      RETURN.
    ENDIF.

    "Ausnahmeklasse
    IF i_object_name(3) = lc_exception_class
    AND i_object_type = lc_type_class.
      CLEAR r_result.
      RETURN.
    ENDIF.

  ENDMETHOD.
<br>

0 Kudos

Hello Uwe,

could you help me out with the coding behind the table view and BOR method?

is_bor_object(...

is_table_view(...

I would like to understand how it works.

Many thanks in advance

Hello markuskraetzschmar2 ,

sorry for the late answer, haven't seen your question until today.

The checks for BOR resp. table views have to be implemented in the satellite system. I'm calling these checks via RFC.

Call in Central system:

  METHOD is_bor_object.

    DATA(src_destination) = COND #( WHEN i_src_destination = '' THEN 'NONE' ELSE i_src_destination ).

    CALL FUNCTION 'FUNCTION_EXISTS'
      DESTINATION src_destination
      EXPORTING
        funcname           = 'ZATC_IS_BOR_OBJECT'
      EXCEPTIONS
        function_not_exist = 1
        OTHERS             = 2.

    IF sy-subrc = 0.
      CALL FUNCTION 'ZATC_IS_BOR_OBJECT'
        DESTINATION src_destination              "normalerweise über DESTINATION 'BACK' in das rufende System
        EXPORTING
          i_object_name         = i_object_name
        IMPORTING
          r_result              = r_result
        EXCEPTIONS
          communication_failure = 0
          system_failure        = 0.
    ENDIF.

  ENDMETHOD.
<br>

Function in satellite system

FUNCTION ZATC_IS_BOR_OBJECT
  IMPORTING
    VALUE(I_OBJECT_NAME) TYPE SOBJ_NAME
  EXPORTING
    VALUE(R_RESULT) TYPE XFELD.

  SELECT SINGLE @abap_true
    FROM tojtb INTO @r_result
    WHERE progname = @i_object_name.                    "#EC CI_GENBUFF

ENDFUNCTION.
<br>

Same logic for table view. Call in central system:

  METHOD is_table_view.

    CHECK i_object_type = 'FUGR'.

    DATA(src_destination) = COND #( WHEN i_src_destination = '' THEN 'NONE' ELSE i_src_destination ).

    CALL FUNCTION 'FUNCTION_EXISTS'
      DESTINATION src_destination
      EXPORTING
        funcname           = 'ZATC_IS_TABLE_VIEW'
      EXCEPTIONS
        function_not_exist = 1
        OTHERS             = 2.

    IF sy-subrc = 0.
      CALL FUNCTION 'ZATC_IS_TABLE_VIEW'
        DESTINATION src_destination              "normalerweise über DESTINATION 'BACK' in das rufende System
        EXPORTING
          i_object_name         = i_object_name
        IMPORTING
          r_result              = r_result
        EXCEPTIONS
          communication_failure = 0
          system_failure        = 0.
    ENDIF.

  ENDMETHOD.
<br>

Function in satellite system:

FUNCTION ZATC_IS_TABLE_VIEW
  IMPORTING
    VALUE(I_OBJECT_NAME) TYPE SOBJ_NAME
  EXPORTING
    VALUE(R_RESULT) TYPE XFELD.

  SELECT @abap_true
    INTO @r_result
    UP TO 1 ROWS
    FROM tvdir
    WHERE area = @i_object_name.     "via DB Index A01
  ENDSELECT.

ENDFUNCTION.
<br>

Cheers, Uwe

axel_jebens
Explorer

Hi Bärbel, hi Uwe,

Just a question: Did you investigate whether the BAdI BADI_SATC_TRANSPORT_OBJECT in enhancement spot SATC_TRANSPORT_INTEGRATION would help you? When I have answered you last time, I did not know that we already provide an exit, at least for transport check.

Would be great if you could check this out and give me some feedback!

Regards,

Axel

0 Kudos

axel.jebens

Hi Axel,

I'll check it out but it'll take a while as I'm currently on vacation.

Cheers

Bärbel

0 Kudos

axel.jebens

Hi Axel,

I quickly checked this in our NW 7.50 SP13 EHP8 system and don't think we can use this - at least if I interpret the cheched box "can only be implemented SAP-internally" and its documentation correctly:

Cheers

Bärbel

axel.jebens

Hi Axel,

after implementing the note suggested by crosenbe in the comment above, I created the BaDI-Implementation and added a bit of logic to it. This gets accessed and works as intended, but apparently only when triggered from within e.g. SE10 for a transport via "Check objects".

I put a break-point in the code but the process doesn't stop there when I run the ATC-check from SE80 via "Check --> ABAP Test Cockpit(ATC)", when I trigger it from Eclipse or when I use cl_satc_object_set_factory from a Z-report.

So, this BaDI unfortunately doesn't seem to be in the right place for what I'd like to achieve.

The other thing I noticed is, that the import table i_initial_object_keys only contains the object-name and object-type (OBJECT) but not also the Program-ID (PGMID). There also often seem to be fewer and in some cases different object-types in the table than what I'd expect to see based on what gets shown for the transport in SE10.

Here is a fairly random example:

Transport shows several items and combinations of PGMID + OBJECT

Only 3 make it into the Badi and they have different values - MSAG instead of MESS, FUGR instead of FUNC and CLAS instead of METH while REPS/REPT are not even represented as PROG

Given all that, I'm not sure if the Badi in its current form and its current position in the process is suitable for what we'd like to do.

Cheers

Bärbel

crosenbe
Explorer

Hi Bärbel,

please check whether note 2670671 will suit your needs, it should make the mentioned transport check BAdI available.

Best regards,
Christian

BaerbelWinkler
Active Contributor
0 Kudos

crosenbe

Hi Christian,

thanks for the OSS-Note which I had implemented today. Now I'm able to create an implementation:

Next step for me: implementing some code as a proof-of-concept and then refining it, most likely with the use of a new Z-table to be able to maintain the "not-to-be-checked" object-types without having to change the code each time another one to exclude is found.

Cheers

Bärbel

BaerbelWinkler
Active Contributor

crosenbe

Hi Christian,

I updated the thread with a reply to axel.jebens as the BAdI isn't working as I had hoped it would.

Cheers

Bärbel

IanStubbings
Active Participant
0 Kudos

Hi Christian

I have used this BAdI successfully in the past but on a 750 system. Now I need to use it on a 754 system but it is not valid. Equally, I cannot create the implementation as it says it is not for customer use.

Is there another solution for 754 and above systems?

Regards

Ian

matt
Active Contributor

Just wanted to say that a well implemented ATC is a joy and helpful even to very experienced programmers like me.

A badly implemented one is so much pain....

christian_d
Explorer
0 Kudos

Hi,

are any news on this topic?

Regards

Christian Dülsen

christian_d
Explorer
0 Kudos

Hello, i found a solution.

Using the mentioned BAdI BADI_SATC_TRANSPORT_OBJECT in enhancement spot SATC_TRANSPORT_INTEGRATION

now works fine.

Just add some coding like this:

METHOD if_satc_badi_transport_object~determine_objects_to_check.

LOOP AT i_initial_object_keys ASSIGNING FIELD-SYMBOL(<ls_object_keys>) WHERE obj_type = 'SFPF'.

e_remove_object_keys = VALUE #( BASE e_remove_object_keys ( obj_name = <ls_object_keys>-obj_name

obj_type = <ls_object_keys>-obj_type ) ).

ENDLOOP.

ENDMETHOD.

Now the ATC Check during Transport Release will not be triggerd for objects in e_remove_object_keys

0 Kudos

christian_d

Thanks, Christian!

However, I just tried in our NW750 SP25 system and the enhancement is still not accesed when I execute a check via SE38. So it'll probably still only be accessed in the course of SE10 logic.

Cheers

Bärbel