Data modeling: Do we need to put process related fields into repository?

[xinjiang_li]

Hi gurus,

Our scenario is regarding central data management. The end users input some master data in the user interface which is developed by using BPM and webdynpro, then after finally approved, the master data flows into MDM system and distribute to different backend systems.

My question is: During the request and approval process, there are some fields like "request reason","approve reason" ( and some other fields which is not important for backend application system), do we need to put those fields in the MDM model? Which option should we choose: sending the master data to MDM untill finally approved, or sending the data in each request or approval step?

Any help will be appreciated. Thanks in advance.

[Former Member · Accepted solution]

Hey Xin,

I would answer your query within MDM space.I understand master data flows into MDM after few requests & approval process is completed.

So, Steps 1 involves- Import of data from other systems into MDM (BPM & WDA to MDM).

Then step 2 involves- Updating MDM with the available data from source system

Step 3: Syndication/export of data from MDM to other backend systems.

Per your query if wish not to send some fields that are not required for backend systems , please make sure syndication process does not include those fields (step 3). You need to concentrate over syndication of data from MDM to backend system.

I think its perfectly fine as long as MDM is updated with those fields- It shouldn't cause any issue. So, adding those fields to MDM model is not a concern. But just need to ensure those fields are not added/mapped to be syndicated further to backend system.

Hope this information helps. Please let me know if any queries.

Regards,

Ali

[xinjiang_li · Accepted solution]

Hi Ali,

Thanks for your reply.

Year, we planned to put those fields in the model, and use checkout and checkin functionality to make sure the data integrity and clean.  The checkoutAsNew function will getback an internalid and create a record,  and after the final approved, the record will be checked in and the real material number will get generated accroding to specific caculation logic ( either at front side or at backed MDM side by using autoid). Am I correct? thanks.

[Former Member · Accepted solution]

Hi Xin,

If i understand correct -Records are initially checked out after flowing into MDM and an internal ID is created for record. Post final approval, the record will be checked In and the Original material number will get generated accroding to specific caculation logic. This sounds good.

Please close this thread if your query is answered. Feel free to let us know if any queries/issues.

Regards,

Ali

[Former Member]

Hi Xinjiang,

The field mentioned sound like Portal specific and possibly used  for navigation purpose.

I dont see any harm in creating such MDM specific fields which wont be sending data to downstream systems.As rightly pointed out above syndication map should not map them to the target fields.

If I understand you correctly,you are talking about how BPM creates/ maintains records in MDM.

So talking about 1st option -

Saving the record in the MDM repository only in the final step.

• BPM context stores the data
• Not recommended because of performance reasons

Coming to 2nd option -

Saving the record after each step

• Only the record ID is passed between the BPM steps
• Ensures record exists in Repository.
• Recommended.

Thanks,

Ravi

[xinjiang_li]

Hi Ravi,

Thanks for your reply.

Year, we planned to put those fields in the model, and use checkout and checkin functionality to make sure the data integrity and clean.  The checkoutAsNew function will getback an internalid and create a record,  and after the final approved, the record will be checked in and the real material number will get generated accroding to specific caculation logic ( either at front side or at backed MDM side by using autoid). Am I correct? thanks.

[Former Member]

Hi Xinjiang,

You mean you would get the recordid with the mentioned function and checkin after approval process.

I agree with you on that.To add to that, you can also rollback at the end if there is a rejection of record.

Thanks,

Ravi