PSA has data, but '0 data packages with a total of 0 records transferred successfully' to DSO

[Former Member]

Hi,

I have a process chain:

Delete Content PSA

Delete Content DSO

Run InfoPackage to fill PSA from flatfile (csv-File) (Full load)

Run DTP to transfer PSA->DSO (Full extraction mode)

The problem:

The DTP for PSA->DSO often produces '0 data packages with a total of 0 records transferred successfully' with status green, while there are over 100.000 rows in the PSA. When I manually run the DTP the data is always transferred correctly from PSA->DSO.

This happens for several similar data-flows (all of them read data from flatfiles I noticed). The load into the PSA always has the correct amount of data, but from PSA to DSO we often get 0 records transferred. This happens on both BWD and BWP but not every time the night job runs.

Do you have any clue why we do not get the data transferred to the DSO?

Here are some screenshots:

View in RSA1:

Log:

This is the status of the PSA, before the DTP PSA->DSO is started:

Process chain:

Any help is appreciated.

br

Alex

[former_member197660 · Accepted solution]

Hi Alex

Please check if there is any routine in transformations/update rules which is truncating the records post PSA processing.

Regards

Ashish

[karthik_vasudevan · Accepted solution]

Hi Ashish

The issue is strange here mate! When he runs the DTP manually, the data is transferred correctly.

So there should be something else apart from routine, since he is executing the same DTP manually which is in process chain.

Regards

Karthik

[Former Member · Accepted solution]

Thank you for you suggestions Karthik Vasudevan,

I noticed that when the process chain is started manually, the problem still occurs.

It does not occur when I manually start the DTPs.

Therefore I looked again at the process chain and changed the following things:

1) There were some connectors between the steps that were configured as "always". I changed them to "when successful".

2) I rearranged the steps in the process chain to:

- delete PSAs

- delete DSOs

- do another task that is not related to the flatfiles->PSA->DSO load.

- then load all PSAs

- then load all DSOs.

I just ran the rearranged process chain and so far all the PSA data is loaded correctly to the DSOs.

Lets see how this works out over the weekend and I will report back on Monday.

br

Alex

[RamanKorrapati · Accepted solution]

Hi,

About process chain there is no issue.

Please check your DTP, whether its full mode or delta mode.

Even check about required authorisation have or not to do the extraction in bw.

Process chains are trigger thru back end used ir.

if your facing above issue when you run manually then it might be authorisation issue.

Thanks

[Former Member · Accepted solution]

Hi Alexander,

Considering the points provided ..(as the load is successfully when you execute manually after checking psa data),there is one case where data load to the dso may go wrong -

If process chain has "always"connectors used bw- deletion PSA,DSO ,Load PSA,DSO.

consider a scenario where psa load fails,and dso load starts before the psa gets loaded .

Here,the DSO will get loaded with 0 records.

In this type of scenario where we require Delete and Full load,we always prefer "Always "connector.

As you have already changed  ..i hope it should work fine now ..

Thanks

[Former Member · Accepted solution]

Hi,

over the weekend the nightjob ran 4x in 2 systems and the problem did NOT occur anymore after the changes I made on Friday.

Therefore I assume these changes are the solution:

1) There were some connectors between the steps that were configured as "always". I changed them to "when successful".

2) I rearranged the steps in the process chain to:

- delete PSAs

- delete DSOs

- do another task that is not related to the flatfiles->PSA->DSO load.

- then load all PSAs

- then load all DSOs.

thanks for your input.

Alex

[karthik_vasudevan]

Hi Alex

This is a strange situation, but I would suggest you to check from the job perspective. Compare the job logs when you run it manually (hope this runs with your username) and the process chain job log.

This might even lead to some authorizations with the ALEREMOTE user id.

Logically, it should give an error when it doesn't have authorization, but we don't have any other clue. So lets start it from there.

Regards

Karthik