Irrelevant Change Pointers for PDS Integration

[Former Member]

Hello,

We will soon have a step change of thousands of Material Production Versions in ERP hence the same number of PDS changes in APO.

In volume testing I ran PDS integration using CFM2 and it worked fine with reasonable run time (using parallel processes).

The problem is that the next time users run curto_create to cif across any new changes, it sends all the changes that have already been sent by CFM2.

This took about 25 hours, far too long for go live on this step change.

I can see that a change pointer has been created by each Production Version change and that CFM2 (initial) does not clear the change pointers so curto_create processes them.

The only way I can think to prevent this is to delete the change pointers just before the CFM2 initial run.

Does anyone have any other suggestion?

Regards

Dave Easey

[Former Member]

Hello,

I think it is transferring in initial mode, please check change transfer indicator should be active in

CURTO_CREATE - Transfer Production Data Structure (PDS) .

BR

Sandeep

[Former Member]

Hi Sandeep, thanks for the reply.

Definitely we are checking the change transfer indicator in CURTO_CREATE.

It seems that Integration Model activation does not change the status of PDS records in the CURTO_PDS_CHG table. So CURTO_CREATE regards the record as a change that has not been processed.

We implement note 1086821 to create the program Z_RSPDSDEL to be able to delete records from CURTO_PDS_CHG.

What I found is that after deletion, Integration Model actvation will re-create a record per PDS in CURTO_PDS_CHG but the Change type indicator will be blank instead of 1 or 3 for delete or change.

If it is blank then CURTO_CREATE will not treat it as a change. When there is a real change the change type indicator will be updated and the next CURTO_CREATE run will process it.

Still I don't know why integration model activation does not set the records to processed.

Regards

Dave

[Former Member]

Hi David,

As per my understanding, If PDS  IM is active  then CURTO_CREATE will transfer the data.

The CFM2 i.e.RIMODACT only transfer the new data to APO, meaning is new Production versions.

If you are preparing for any go live activities  then do the initial  transfer by RIMODINI.

Or also you can correct the data ECC/APO. from T.code : /SAPAPO/RTO_ORD_COMP - Comparison of PP/DS Production Data Structure .

BR

Sandeep

[Former Member]

Thanks again Sandeep.

I just tested again to be sure of myself.

The issue is that RIMODINI does not set the PROCESS flag in the CURTO_PDS_CHG table.

We will make 70K changes to Production Versions then run rimodini to bring the changes to SCM.

After rimodini has finished we will still have 70k records in CURTO_PDS_CHG that show CHANGE = 1 and PROCESS = blank.

So when the users next run CURTO_CREATE (change transfer mode only) to process subsequent changes, it will transfer 70k records again.

You might say why not use CURTO_CREATE to transfer the 70k records in the first place. The reason is that rimodini can run with parallelisation but CURTO_CREATE cannot so it is a lot faster to use rimodini.

/SAPAPO/RTO_ORD_COMP is not useful for us because we are using SNP PDS not PPDS PDS.

Regards

Dave

[Former Member]

Hi David,

In last month I had carried out PV change activity in production system for about 15K PVs.

I was divided the lots each of 5K  and transferred through CURTO_CREATE and there was no performance issue .

You can try  70 K by dividing it smaller lot and use CURTO_CREATE.

You can also try  (provided you should have BDC  for PV creating in ECC )

1) Delete the PVs in APO

2) Delete the PVs in ECC

3 )Use  CURTO_CREATE. (I think deletion will fast as compared change/create)

3) Create changed PVs in ECC.

4)Activate IM model for PDS.

BR

Sandeep

[Former Member]

Thanks again Sandeep.

From my testing so far then after your second 3) we will have 70k records showing new PV, CHANGE = 1, PROCESSED = blank in the CURTO_PDS_CHG table.

Then after your 4) we will still have 70k records showing CHANGE = 1, PROCESSED = blank in the CURTO_PDS_CHG table. This is because IM activation does not update the table.

So my issue still remains. The next time curto_create is run it will process all 70k records, not just the ones that have changed since APO was updated by the IM activation.

My solution works fine, I just don't understand why it should be needed.

Regards

Dave