cancel
Showing results for 
Search instead for 
Did you mean: 

0soursystem !!!

Former Member
0 Kudos

Hi all,

If we only have one source system, should we get rid of the 0soursystem?

There are a lot of works to do if we install a std object. Always has inconsistent compounding with one object that references another info objects. We always need to perform a Where-Used list to find all the compounding infoObjects that the referenced objects contain, and add all of them.

If we decided to get rid of the 0soursystem now, this is also kind of open-heart surgery for all DEV, QA, and Prod systems?

Can anyone shed some lights on this issues?

Thanks,

Kev

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

u may be having a single source system right now..

But source systems or clients might be added anytime in the near future.

I would advise that you keep this infoobject.

Anyway I dont think anyone goes for deletion of BC infoobjects(even if they arent required).

cheers,

Vishvesh

Former Member
0 Kudos

Hi

I would advise you not to remove 0soursystem because-

Apart from being it's a huge work , you might end up having to re-load your entire transaction data . This is because to remove sourcesystem , you need to change lot of infoobjects and possibly delete the master data . Once you delete the master data then SIDs of the loaded transaction data will not match with newly loaded master data (assuming that you load master data again ) and then you will have to delete & re-load the transaction data again .

So you are advised to let the 0soursystem object be there ...you might need it in future.

Regards

Pradip

Former Member
0 Kudos

Hi all, thanks for the message!

Have you experienced any troubles when you imported BC because of the 0soursystem?

We had a lot of work to do after importing the new BC. It always claimed that the 0sourcsystem is not compoounded with the objects.

Thanks all,

Kev

former_member188975
Active Contributor
0 Kudos

Hi Kev,

It is true that BC installation is a bit difficult with 0SOURSYSTEM compounding...OSS note 184948 (Compound Infoobjects to 0SOURSYSTEM ) talks about this in details.

Hope this helps...

Former Member
0 Kudos

Hi Bhanu! Thanks so much for your help! I read through the note you mentioned and it is exactly what I mean.

I need your advice. If we are sure that we only have one system and we can afford to shut down the system for a week to reload all the data, do you think it is worth it to get rid of the 0SOURSYSTEM for the sake of simplicity.

Or we'd better keep the 0SOURSYSTEM and apply note 184948 everytime we import new BC with 0SOURSYSTEM compounding.

Our team has decided to get rid of it, I just want to make sure that if it is worth the effort. In the future, if we decide to migrate international data, we will use a new BW system to handle it.

Thanks,

Kev

Former Member
0 Kudos

Hi all,

If we really decided to get rid of the 0SOURSYSTEM, is there any efficient way to do that?

Can I write a ABAP program to update all the infoobjects' fields like compounding object(IOBJCMP) and attribute (ATTRINM) at once?

Or we have to manually change them with transaction RSA1?

Or any transactions can do the work for us.

Thanks,

Kev

former_member188975
Active Contributor
0 Kudos

Hi Kev,

I agree that maintaining the 0SOURSYSTEM means doing some extra work during business content installation, and if there is only one source system (or more than one but with consistent master data) then 0SOURSYSTEM is not required throughout the system.

To "remove" it you will have to proceed by deleting all the data in the system, removing from the data targets and then removing it from the InfoObjects...this may be a bit tricky for the same reasons as adding 0SOURSYSTEM during business content installation. The moment you remove it from an InfoObject, and try to activate, the system will check for dependancies and prompt you for consistency.

Hope this helps...

Former Member
0 Kudos

Thanks Bhanu,

We are aware of the trouble of removing it. We believe this one time clean up will help us to have better development in the long run.

We also aware of moving objects from Dev to QA and or Prod may cause problems. For example, Transfer Rules may have additional ABAP routines; InfoObjects may -


have additional Attributes, etc. These changes may be in development and not be ready for QA and or Prod.

That's why I am thinking if it is possible to write a ABAP program updating the field of compound and attribute if they contain 0soursystem. Then I could do the same thing in QA and Prod directly without transporting. Again, transporting from dev to QA or Prod will cause lot more trouble due to the work done in Dev might not be ready for QA or Prod.

Thanks,

Kev

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Kev,

Can you be a bit more clear and give some more details regarding your question.

Regards

Sajeed