Two internal tables are not compatible or convertible - MDG-M

[benjamin_allsopp]

Hi,

I'm am currently extending MARM and the UNITOFMSR entity with some custom fields.

Here's what I did:

• Extended MARM
• Extended SMEINH (change table for MARM)
• Extended the MARM X and UI structures
• Added the fields on to T130F
• Added them to Data Model
• Generated structures
• Did SMT mapping
• Adjusted Staging for MM
• Cleared the UI Metadata buffer
• Added fields to UI
• Added some rules in the rule service to default the fields in certain circumstances  (I know this is not the problem because I commented out all the new code and the issue is still happening)

Here comes the problem - whenever I try to start or continue a process in MDG I get a short dump with description:

Two internal tables are not compatible or convertible

I have extended hundreds of fields the same way and never encountered this issue. The dump is happening in standard method read_entity_buffer of class CL_USMD_GOV_API:

CREATE DATA lr_data LIKE LINE OF et_data.

* analyse requested data structure

* this has to be done anyway as the write buffer needs the component table too.

* For this reason we get it here and provide the result in et_components

* to be reused then in WRITE_ENTITY_BUFFER.

   lr_data_struc ?= cl_abap_typedescr=>describe_by_data_ref( p_data_ref = lr_data ).

   lt_components  = lr_data_struc->components.

* Try to read the data from the READ BUFFER

   READ TABLE mt_entity_read_buffer WITH KEY entity       = iv_entity_name   "key

                                             entity_key   = <ls_key>         "key

                                             edition      = iv_edition       "key

                                             read_mode    = iv_data_source   "key

                                             request_mode = iv_request_mode

                                             components   = lt_components

                                   ASSIGNING <ls_buffer>.

   IF sy-subrc = 0.

     ASSIGN <ls_buffer>-result->* TO <lt_data>.

     CHECK sy-subrc = 0. "Write was not called-> Exception raised by READ/RETRIEVE_CHAR_VALUE

     et_data  = <lt_data>.

I've highlighted in bold the problem when it hits one of the UNITOFMSR buffer entries. I can see no difference between et_data and <lt_data> at the time of the dump except that et_data is a sorted table and <lt_data> a standard table.

Any ideas on what could be causing the problem and how to solve?

[shaila_kasha]

Hi, i am facing similar issue for Unit of measure entity.

At runtime, debug mode - a reference structure of unit of measure entity is created which does not match the data model structure. An insert statement is called and because of miss matching structures, we are getting dump in the system.

This is happening in one of our landscape and not all.. I tried below and no luck yet.

run report - USMD_ADJUST_STAGING

run report - USMD_ADAPT_BRF

MDGIGM- clear UI metedata buffers

[dneu · Accepted solution]

Hello Benjamin,

did you find a solution on that issue. I am facing the same issue here but on MATERIAL entity.

Best regards,

Daniel

[benjamin_allsopp · Accepted solution]

Hi Daniel,

Yes I found the solution to my problem.

Basically it was to do with alignment gaps. When the first field of an extension on the entity is of a certain type (floating point etc.) The system inserts alignment gaps. I could have changed the name of the first field so that the first one became of type  so that it aligned properly. But as the naming convention was important to me I instead inserted as the first field on the extension a dummy field of type c.

Once I had done this the alignment gaps sorted themselves out.

I can give you more details about how to find out if this is the case for you in a couple of days. But I have no access to my notes until Thursday.

Hope this helps.

Ben

[dneu · Accepted solution]

Hi Ben,

thank you for that just-in-time reply!!!

I could figure out that our problem is with a field that uses INT4 as domain. When I kick it out of the datamodel it is working. If I put it in again with other names or whatever it is not working.

I now need to figure out what can solve the issue...

Daniel

[benjamin_allsopp · Accepted solution]

Hi Daniel,

As promised - it is Thursday and I have access to my notes from SAP:

This is a rare issue that happens only in Unicode systems where Include starts at an odd offset and with specific types of fields, so this is why it does not occur often.

The Read Entity Buffer of the Governance API stores structures created from different sources and at different levels of the code stack (Convenience API, Governance API, Model, etc..). Depending on where these structures are created, some of them could be created through data references of the Data Model in customizing (in this case Flat structures), and others could be created through references of the Primary Persistence mapping structures such as /MDGMM/_S_MM_PP_MATERIAL.

In ABAP Include structures, there are Alignment requirements introduced due to the use of Unicode systems, and because of this Alignment gaps would be inserted to satisfy these requirements. On the contrary, flat structures would automatically align themselves and no Alignment gap would be inserted in this case.

For more info and rules on Alignment, you can check the following links:

Alignment

https://help.sap.com/abapdocu_70/en/ABENALIGNMENT_GLOSRY.htm

Alignment in Unicode Systems

https://help.sap.com/abapdocu_70/en/ABENUNICODE_ALIGNMENT.htm

Alignment of data objects:

https://help.sap.com/abapdocu_70/en/ABENALIGNMENT.htm

The use of a data type P (or INT4?)  at the start of the include would result in an alignment gap being inserted until the Include structure is aligned, whereas the use of a data type C would automatically align the Include and no gap would then be inserted.

In order to check the offset of each of the fields of structure /MDGMM/_S_MM_PP_MATERIAL, go to transaction SE37 and execute Function Module DD_SHOW_NAMETAB. Fill in the following parameters, click execute, then click on 'Display output list of function module' to show the detailed structure info:

SHORTNT = <blank>

STATUS = A

TABNAME = /MDGMM/_S_MM_PP_MATERIAL

GETALL = X

Comparing this to the snapshot of the structure will show any misalignment caused by alignment gaps.

As I said - to prevent this from happening all I did was create a dummy field at the start of the include (in the data model) called ZZADUMMY. This naming convention placed it at the top of the Z-fields for my structure. And It was a type C (incidentally I used length 2 because this was the size of my alignment gap but I don't think this is important)

Thanks,

Ben

[former_member191125]

Hello,

Even I used to get the same error.

Please follow the below steps,

1. Activate Data Model one more time.

2. Activate structures in MDGIMG corresponding to your entity.

3. If there is SMT Mapping remove the SMT mapping and save one more time.

4. Re-create SMT mapping then save.

5. Run Adjust staging reports.

This will resolve your issues.

Thank you,

Girish

[shaila_kasha]

Hi, i am facing similar issue for Unit of measure entity.

At runtime, debug mode - a reference structure of unit of measure entity is created which does not match the data model structure. An insert statement is called and because of miss matching structures, we are getting dump in the system.

This is happening in one of our landscape and not all.. I tried below and no luck yet.

run report - USMD_ADJUST_STAGING

run report - USMD_ADAPT_BRF

MDGIGM- clear UI metedata buffers

[former_member188878]

Bejamin,

recently any upgrade you guys have to the MDG system....

[benjamin_allsopp]

No upgrades - We've been on Release 618 SP4 since we implemented the system in October.

[former_member188878]

Please check the entries in both the tables for sorted tables they required right key to insert the values.

also check the generated staging tables have this fields.

[benjamin_allsopp]

The sorted table has no entries.

The standard table has one entry with all the standard keys for MARM/UNITOFMSR.

And the all the generated tables have the added custom fields. Even when I am in debugger on the statement it fails at I can look at both the tables to see that apart from the table type (sorted-standard) they are exactly the same in structure.

I don't understand it as I have not touched the standard keys for this entity.

what's more, I have taken them all out and started added them one by one. Of the 9 fields. Two of them can be added and keep it working. The rest all cause the dump despite all being using the same data element in all the generated and database tables.