cancel
Showing results for 
Search instead for 
Did you mean: 

Check-in/check-out is required for flat tables

Former Member
0 Kudos

Hi everybody,

For master data maintenance scenario it is required to have check-in/check-out functionality in MDM. As I know it is supported only for main tables in MDM 7.1. But it is required to maintain flat tables too. Is it ok to change flat tables type to main (delete flat and create main with the same structure) to have check-in/check-out functionality available? Will it be performance or any other impact, or other limitations?

Thanks in advance,

Alexei

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Alexei,

If the requirement to achieve check In/Check Out functionality is a must then you might think of adding those certain fields to main table rather than changing the complete structure of table. Changing structure of table means disturbing whole lot of associated systems(involves xsd,xml,maps).

But if you project is just into initial stages and you wish to try this option, then i would say go-ahead.

But if things are already running smoother into production and you plan to chage structure then it would distract lot of systems.

Regards,

Mir Ali

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Alexei,

There should be no issue with that.

From best Practice point of view SAP recommends to make a table Main table if it is to contain more than 10000 records.Even if you have a lot fewer records it should be fine making a lookup flat as lookup Main.

I have a query here - why do you want to make lookup entries as CheckedOut?

Is it to govern creation or to make them unavailable till the time they are approved/confirmed?

Thanks,

Ravi

Former Member
0 Kudos

Hi Ravi,

>> Is it to govern creation or to make them unavailable till the time they are approved/confirmed?

Yes, exactly. And to have possibility to do roll-back if changes are not approved.

Regards,

Alexei

Former Member
0 Kudos

Hi Alexei,

I am listing down few ideas to achieve this -

> You may want to use BPM to write the lookup data only if it is confirmed.BPM will not write the data till it is confirmed.

> Maintain Flag in the lookup record.a record with TRUE will only be usable.You can control this using portal,named searches,constraints etc.Those lookup records which get rejected can be deleted manually or automatically.

> Maintain a temporary staging table and hold it till the time of approval.Once approval or rejection happens delete it form the staging table.On Approval write the same data on the correct lookup using portal/syndication and import etc.

Thanks,

Ravi

Former Member
0 Kudos

Hi Ravi,

thanks. I'm already implementing solution very similar to your second proposal. It's the most suitable for our case.

Regards,

Alexei

Former Member
0 Kudos

Hi Alexei,

Thanks for sharing,I am glad it helped.

It would be helpful to keep the flag as FALSE till the time approval is pending and once approved status can be changed.

In case of mass imports the flag can hold fixed value as FALSE for all imports,if approval takes place after import.Otherwise TRUE is right selection as approved records only get imported.

Thanks,

Ravi

former_member182652
Participant
0 Kudos

Hi Alexei,

As such there is no hardcoded/theoretical limit on the number of main tables in a repository. But the sizing for MDM depends on number of records in main tables. So, i suggest that you check the sizing guide once in case the volume of records in flat tables is too high, else you can go-ahead with the changes if your project is in initial stage.

Regards,

Kunal