BOBX - ddic generation fails

[Former Member]

Moin, moin,

I am using the following Settings when re-generating the ddic structures of my BO:

I am getting the following error and do not know how to proceed:

All data base tables are not re-generated with the message:

TABL ZLT_IP_PA_ROOT delivered to customer (action not possible)

All mentioned tables appear as data base table in my three nodes.

Any hint how to proceed are welcome.

Regards,

Thomas

[former_member190794]

Hello Thomas,

is the "Enhancement Category" of those tables different from the "Enhancement Category" you have chosen in the regeneration screen? Not sure if you can change the enhancement category of database tables that are already transported back to "cannnot be enhanced" (as their might be enhancement already built on them out there). So this error seems not to be BOPF specific but related to transporting tables in general.

Best regards

Tilmann

[Former Member]

Hi Tilmann,

Thanks for your hint.

I just checked the versions of the database tables. The enhancement category was not changed and is "can not be enhanced" for all versions of these tables.

Has anybody others Suggestion how to proceed?

Regards,

Thomas

[ivo_vollrath]

Hello Thomas,

could you please check if this message is created by method CREATE_DDIC_OBJECT of /BOBF/CL_CONF_TOOLBOX?

In that case we would have to investigate if a check which was originally only meant for SAP-internal systems is accidentally being executed for customer developments. The reason for the check is that changes to existing DB tables can cause incompatibilities when transported to productive systems which have already been using the table. (Is this the case for you?)

If the tables have been generated by BOBX before, you may be able to circumvent the problem by manually deleting them before re-generation.

Disclaimer: I assume you "own" the tables and you know what you are doing.

Kind Regards,

Ivo

[Former Member]

Hi Ivo,

Thanks for your reply.

Yes, I own the tables as I created them in Z name space.

The messages are created in the method you mentioned above in section:

* check if database is already delivered and reject regeneration
   IF iv_object = 'TABL' AND iv_database = abap_true AND lv_mode = 'MODIFY'.
     lv_name = iv_name.
     CALL FUNCTION 'TR_GTADIR_DELIVERY_STATE'
...

ELSEIF lv_status = 'K'.
       IF 1 = 0.
         MESSAGE i601(e2) WITH iv_object lv_name.     "#EC CI_USE_WANTED
       ENDIF.
       ls_msg-msgid = 'E2'.
       ls_msg-msgno = '601'.
       ls_msg-msgty = 'E'.
       ls_msg-msgv1 = iv_object.
       ls_msg-msgv2 = lv_name.
      eo_message->add_message(
          iv_node = iv_node_key
          iv_key  = iv_key
          is_msg  = ls_msg ).
       ev_failed = abap_true.
       RETURN.
ENDIF.

Regards,

Thomas

PS: I am quite sure what I am doing

[ivo_vollrath]

Hi Thomas,

Thanks for checking. In fact I assumed that you know what you are doinig but I did not want to be blamed for telling someone to delete a table he did not "own".

As I mentioned before, the intention of this check is to prevent unexpected incompatibilities. We briefly discussed if we can remove the check in non-SAP systems, but we currently think this would be too dangerous. We may improve the error message in future SPs, though.

If you need to make changes to generated BOPF tables which have previously been transported, you will either have to do these changes manually (that is using the standard DDIC transactions) or you can delete the table and let it re-generate.

Kind Regards,

Ivo

[Former Member]

Dear Ivo,

If you need to make changes to generated BOPF tables which have previously been transported, you will either have to do these changes manually (that is using the standard DDIC transactions) or you can delete the table and let it re-generate.

How should an ongoing project or also just normal operations work with BOPF with such a restriction? From what I understood one idea of BOPF is to have a consolidated / harmonized way of "abstracted" data modelling.

In case you need to throw away this approach after the first release of your project from dev-->test and start to work with basic SE11 dictionary tools again, one big advantage of BOPF is basically gone...

Deletion of a table is also not a real solution - The tables are normally not empty and contain real data. It's not really acceptable to store & reimport test-data within every sprint..

The reason for the check is that changes to existing DB tables can cause incompatibilities when transported to productive systems which have already been using the table. (Is this the case for you?)

Is there any BOPF specific incompatibilities which can occur? Or just the "normal" inconsistencies when changing DB tables? In this case I do not see any advantage for the customer doing it in SE11.

In both cases the developer has the same risk. Actually he even has more risk with SE11, as the developer is doing changes on a generated table, which is actually "owened" by the BOPF framework and not really by the developer.

Thanks,

Timo

[former_member190794]

Hello Timo,

I agree with you that it would be possible to support incompatible changes (like for instance deleting fields, incompatible type changes or switching the enhancement category) more comfortable by the help of the BOPF tools instead of refering to the commmon DDIC tools in such exceptional cases.

However those mentioned incompatible changes usually do not happen very frequently
- at least I can't remember any doubts about the current behavior in the past and thus we invested more in providing you some great new features instead.

Best regards
Tilmann

[Former Member]

Hi Tilmann,

First thanks a lot for your very fast reply. Let me maybe rephrase.

We have deployed an bopf object to our test-system. Now we want to add a new alternative key in the bo object in dev system in eclipse. This new alternative key is required for a new functionality.

During activation BOPF is trying to create a table index for the alternative key. Due to that both TABL & INDX Objects are adjusted in /BOBF/CL_CONF_TOOLBOX , CREATE_DDIC_OBJECT.

==> Due to the delivered status of the table, the change is rejected.

It seems that it is simply not possible to create a new alternative key for an delivered bo with eclipse - As BOBX is not creating the table index automatically (with 7.50/SP3), we can use the BOBX transaction at least for that purpose.

Is this case here a bug (or just wrong usage)?

In general: How are you handling the change of SAP internal BO objects in case of table / index enhancements? Delete the table and let it recreate by the framework? Or really work manually?

Thanks,

Timo

[former_member190794]

Hello Timo,

from my perspective it should be possible to at least get the creation of the alternative key in the BOPF model done. So we will check the current behavior and inform you here about news. You can also add a ticket on component BC-ESI-BOF if you would like.

Best regards

Tilmann

[Former Member]

Dear All,

In case you also have this issue (alternative key can not be created using eclipse for release BOPF object).

SAP has released note 2366131.

Regards,

Timo