Question Re: ADSO fields getting empty post data activation in Technology Q&A

ADSO fields getting empty post data activation

aalbis — Tue, 21 May 2024 15:10:23 GMT

Dear SAP experts,

Recently I have converted a "Data Mart ADSO" to "Standard ADSO with Write Change Log".

In DEV environment everything looked fine.

- data was activating correct

- fields were populated correct

Once I moved the changes to QA, some fields which were fine in DEV, are getting empty once I activate the data. What could be the reason? I have no start/end/field routine for these fields. It's just 1:1 mapping from datasource -> staging adso -> integrated layer adso.

Additionally, I tried to reproduce the issue in DEV by copying the same ADSO to a new test one and trying to do the conversions on the test one: Data Mart - Standard and reverse, the issue is same like in QA. Only for the old ADSO everything works fine in DEV.

What could cause this issue? Please advise, I need urgent help 😞

Ideally I would like to apply a fix to the old ADSO (not the test one) so everything will work fine in QA for it and no fields would get empty post data activation.

Please help!

Re: ADSO fields getting empty post data activation

MKreitlein — Wed, 22 May 2024 06:52:11 GMT

Hello @aalbis. It would be interesting to see your key fields in the newly converted ADSO! I would say it is maybe the problem that you don't have enough key fields now and that some records with initial values overwrite others with characteristics available?!

Re: ADSO fields getting empty post data activation

aalbis — Wed, 22 May 2024 07:32:31 GMT

Greetings @MKreitlein

As keys in the converted ADSO I am using the same ones as the extractor (which is a standard CDS View) -> IFIGLACCTLIR.

1. Source Ledger

2. Company Code

3. Fiscal Year

4. Fiscal Year Variant (added automatically when adding Fiscal Year, as it is compounded)

5. Accounting Document

6. Accounting Document Line item

I simply cannot understand why some random fields like 0FI_DBCRIND, 0SEGMENT, 0FISCPER, 0FISCPER3, which are 1:1 mapped from source to integrated layer, get blank POST data activation. Until the inbound table they are fine. Once the data gets activated, they are blank. Even in the change log they appear as blank.

I have no specific logic applied to these fields, such as lookups, end/start/field routines or formulas.

I have tried the following:

- reload the data;

- activate the adso again using RSDG_ADSO_ACTIVATE program

- create the column view again usin RSDDB_LOGINDEX_CREATE

Will SAP support on this issue in case we open a ticket?

Many thanks to anyone who can provide a tips or any idea regarding this matter!

Re: ADSO fields getting empty post data activation

MKreitlein — Wed, 22 May 2024 09:04:48 GMT

Hello @aalbis

I found this in the Support Portal.

I have no idea about your release, but maybe it helps?!

2375939 - Request activation in an aDSO leads to blank/initial values in non-key fields as the field aggregation behavior is incomplete

BR, Martin

Re: ADSO fields getting empty post data activation

roland_szajko — Wed, 22 May 2024 12:45:07 GMT

I would suggest to first really check the KBA that was provided by @MKreitlein. Also ensure, that before and after image pairs of the same key are processed within the same package. Otherwise it can happen that the before image is processed on it's own, which leads to the initialization of data fields.

Also check:

Re: ADSO fields getting empty post data activation

aalbis — Thu, 17 Oct 2024 08:59:16 GMT

Hello everyone! Sorry for the delay and many thanks for your inputs. Just to give you a brief to your questions/recommendations. I was using the same key fields in the aDSO as the Standard SAP CDS view used for extraction. Somehow I think the TRFN got corrupted due to the switch of the aDSO type. After I added 2 more fields (non key) and reactivated the aDSO/TRFN, the activation of the aDSO data worked fine. It might sound strange, but this was the solution to my issue

Re: ADSO fields getting empty post data activation

aalbis — Thu, 17 Oct 2024 09:00:03 GMT

thank you Martin! I had a look but my issue got resolved somehow different. I posted the solution above. Really appreciate your input!