cancel
Showing results for 
Search instead for 
Did you mean: 

Loading infoobjetos standard master data from different source systems

Former Member
0 Kudos

Hello,

The project on which I need to load in the master data tables infoobjetos some standard, master data from two different R3 systems, one being that of Spain Portugal and the other is for Greece.

Currently, available data in these tables come from Spain Portugal and Greece want to incorporate, but we found the problem that for some cases have the same code, and instead of generating a new entry in the data table what teachers do is overwrite the existing entry.

And it's not really what you want.

In the parameterization of the IO, I have seen in the relationship tab, mark 'teachers are localm.válidos p.sistemas Data source (ind.)

'I think that may be related to this I am telling you.

But it's something I have not ever used, and not how it works and what impact can cause data models and BI system developed in Spain and Portugal.

Anybody can give me some information about this topic?.

I tried to find documentation, but I see nothing.

Regards,

Pmarques

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

Maintain 0SOURCESYSTEM in the compounding attributes.This will solve your problem.

Regards,

Shiva Kumar G.C

Former Member
0 Kudos

Hi Shibu,

But if I put the 0sourcesystem as an attribute of the standard features are not overwritten the master data from one system to another because the key issue?

For example, in 0DISTR_CHAN standard feature, I'm like the feature attribute 0sourcesystem and load the following data from different systems:

Distribution channel (key field) Id source system (attribute)

Spain R3 - AA E3

Greece R3 - AA G3

The record from the master data table overwrite Greece to Spain, and one would have an entry in that table with that key.

Regards,

former_member222556
Contributor
0 Kudos

Hi Dear,

For this you have to write the Code at Field LEvel Routine in Transformation or Update Rule on Key Field

Distr. Channel

data RResult(30) type c.

Concatenate Source_fields-<Distr. Channel> '_' to RResult

Concatenate RResult source_fields-0sourceSystem to RResult

Result = RResult.

Here we are concatenating the Source system and key field of mater data table so that every record will distinct and will not over write.

If any doubt in Code, please let me know.........

Regards

Obaid

Former Member
0 Kudos

Hi Obaid,

Sorry, but I do not understand your proposal.

I have the characteristic 0DISTR_CHAN distribution channel whose data type is a char 2.

If the AEP source system whose id is 'E3', rushing to my channel distribution bw = 'LP'.

You offer me concatenate 'LP' with 'E3' and the result would LP_E3, which would be the key distribution channel ... but if this value I get from the chain is a char of 5, I can not carry on 0DISTR_CHAN standard feature since it is a 2-char ...

former_member222556
Contributor
0 Kudos

Hi Dear,

can u please change the length of Char. Distr. Channel, for that goto

-->RSD1 -->Enter charactristics name click on Maintain >Change the length>Activate

and then try the above code

Regards

Obaid

Former Member
0 Kudos

Hi Obaid,

Possibly use the alternative I comment, but wanted to make sure the impact would have on my system bi, the change in length of an IO that is used in the cubes created for Spain Portugal.

I tried to change the length to 0plant IO, and when it goes active the following warning:

0PLANT Feature: Extension can be problematic (-> Text expl.)

Message No.: R7042

Diagnosis

The 0PLANT feature length has been extended from 000004 to 000007.

Activities in the system

In case the property itself is made or displayed in the composition of other features, property values will become invalid if they are filed in a concatenated (eg., In hierarchies). In certain circumstances, the property can not be activated.

The affected objects are found here.

Procedure

0PLANT extended only if the feature is certain not to be used in hierarchies or other property as mentioned above.

Or check the consistency of the items listed above or set the objects if necessary.

Note:

The feature can also be used in hierarchies of other features like node.

Objects affected:

Hierarchies - hierarchies also other features. Affects the use of leaves as the use of nodes in the hierarchy.

The property can not be activated if you have hierarchies or hierarchies are used in external.

Document Properties: The concatenated values are stored in the document property value property of the master data documents and document properties for documents Infositio data.

The property can not be activated if you use values in the document properties.

Filter values in Excel workbooks and query views.

The feature can be activated. Workbooks and query views have to be adjusted if necessary.

Example

The store (length 4) is related to the center (length 2). If at one level (or in the leaves) of a hierarchy (or other files) are data store, property values will be grouped in a field. The store "ABCD" in the middle "XY" will be recorded as the value "XYABCD."

If the property which may extend from 2 to 4 positions, the value "XYABCD" in the hierarchy after the amendment shall be construed as a storage "CD" in the center "XYAB." Thus, the hierarchy will no longer be usable.

Likewise, the values are inconsistent if a feature is included in the relationship or if the sequence of the relationship is modified.

After reading this, my questions are:

- I have to check if the feature is hierarchy or used in other hierarchies?

- I have to check if used to calculate a composite field?

- If used on a routine abap, to obtain a field?

- Would have to change something in the current data model of Spain Portugal (Cubes, ODS, rules), which would imply to me a full load initial cubes?

Would need to resolve these questions before you touch anything.

Escuchar

Leer fonéticamenteDiccionario - Ver diccionario detallado

former_member222556
Contributor
0 Kudos

Hi Dear,

Donot worry , it will not affect your data that is loaded in the cube but you have another option to make a copy of that info object and load the data in that.

Regards

Obaid

Former Member
0 Kudos

Hi,

Sorry for the late reply.

When you add source system attribute as compounding it becomes a key field of master data tables along with the characteristic . So one value of characteristic can be assigned to a particular source system uniquely. If it is not a compounding attribute then it will not be a key field in master data tables.

So maintain the source system as compunding attribute not juts the attribute.

Hope this help you.

Regards,

Shiva Kumar G.C

Former Member
0 Kudos

Hi Obaid,

I finally decided on the alternative of creating a copy of the standard infoobjeto, and infoobjeto copy (Z *) extend the length of the data type for loading a compound key for the value of the field that comes from the source system + a suffix two characters to identify which system is loading the master data.

But now I have another problem, I need to change the output length of the feature to that in typical samples querys just me the correct value of the field, coming from the source system, not the composite key.

That is, if I believe the infoobjeto ZPLANT (center), and I'm like length of 7, the output length I want it to be 4.

Value stored in the master data -> Z001_ES

I must show courage in the querys -> Z001

Do you know how I can change this? If there is a conversion routine that you perform?

Thanks.

Answers (3)

Answers (3)

former_member188011
Active Contributor
0 Kudos

Hi:

I think it is worth to evaluate the use of Consolidated InfoObjects, for more details check the documentation below.

"Integrate your Data in SAP NetWeaver BI using Consolidated InfoObjects" blog by Richard Putz.

/people/richard.putz/blog/2007/02/22/integrate-your-data-in-sap-netweaver-bi-using-consolidated-infoobjects

"Integrate Information from Disparate Sources Using SAP BW Consolidated InfoObjects" presentation by Jie Deng.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f3449b90-0201-0010-f3af-8c3346c6a...

Regards,

Francisco Milán.

former_member222556
Contributor
0 Kudos

Hi Dear,

Whatever Murali said that is absolutly correct, but instead of writtng that code in transformation you can write it in globle routine that will good for future also. you donot have to worry about that once u specify that ingloble routine of that infoobject

Result = sy-sysid.

Regards

Obaid

Former Member
0 Kudos

Hi Obaid,

Do not quite understand your proposal was not what you mean with the overall routine infoobjeto. Could you explain better and in more detail, please?

Regards,

Former Member
0 Kudos

Hi,

You could do 2 things to overcome this prob.

1. Append a source system identifier to the master data values....like 10000_10 comes from one country and 10000_20 from another. You could do this in the transformations/rules.

2. Compound the master data object with 0sourcesytem infoobject. Then the key would be the master data object and sourcesystem. This way the values will not get overwritten.

Former Member
0 Kudos

Hi Murali,

The ideas I have raised are good, but I find a number of drawbacks including:

1. If I use a standard IO, whose data type is a char 5 and the values that I carry in it, conform to the type of data, I have no hole in the feature to assign one or more extra keys to distinguish data teachers and other systems.

2.This option had already seen me, but I see cause quite an impact on data models that are currently developed bw for Spain \ Portugal.

It would have to modify infofuentes, transformation rules, features, buckets, querys, to include 0sourcesystem in all these objects.

Are not there other alternatives that cause less impact and do not involve a change in mass of objects in SAP BI?

Regards,