After activating datasource system asking for Package & TR for object. But the status still in red. In old replication this is common and we still can replicate it in our BW System. But it turns out the green check icon represent the Release Datasource for ODP.

then I’ve found out that not all Data extractor of Datasources is supported by ODP from here . I check on table ROOSATTR in ECC System, but my failed replicated datasource already there.

“The ODP API does not show all Extractors, it only shows the released ones. The idea is that over the time multiple Extractors have been developed by SAP, some became obsolete, some might not work with this API. So along with the ODP API a new table is created in the dictionary called ROOSATTR containing all the Extractors the API and hence DataServices 4.0 supports.”

SAP extractors: Most of the delivered SAP extractors are already released for ODP replication. You can release the corresponding DataSources in your SAP source system by implementing this SAP Note in your source system and then executing the program BS_ANLY_DS_RELEASE_ODP in the relevant source system. Pay attention to the restrictions that apply to the ODP release described in SAP Note 1932459 and KBA 2407906.

So i run the program BS_ANLY_DS_RELEASE_ODP in Development & Testing Client for Source System in BW. Voila! The status in RSA5 & RSA6 my active datasource already turn into green, which is activated for ODP.

If your datasources still not activated for ODP, in notes also saying that,

For other SAP extractors that are not currently released for ODP replication but that you require, please open an incident in the application component BW-BCT-GEN.

It was started couple days ago. Two of my colleagues reporting issue regarding write back data on a BPC Environment Model. We’ve never have this problem before. The write back engine run smoothly on every model in every situation.

So, my first attempt I try to by pass this procedure by change flag ds_wb_param-execute_badi into abap_false.
But, on the following step there is more validation for this exception.

My second attempt would be checking the the object of lo_badi which reference into BAdI badi_ujr_write_back. There are two implementations using this enhancement spot. I’m guessing since this implementation we need to input appset_id, application_id, & module_id so we get the right implementation.
But the write back we used comes from standard process, it doesn’t make any sense if the implementation doing something wrong with standard process. So I crossed this possibility and start to think another option.

Then I tried to debug deeper.
The next guess would be my third attempt.
I found the same exception showed on method CL_UJV_VALIDATION_MGR -> CHECK_VALIDATION.
Try to dig deeper, I found the table UJV_MODULES which for BPC Validations – Module On/Off Table.
And there is only one record for that model. *AHA

So i googled little bit then found out that TCode UJ_VALIDATION which generate the record for tables UJV_MODULES.

Then I ask permission one of my senior if he still using the validation or not. Then Turning off validation for that model. It works like a charm.
Problem Solved

for further information on how UJ_VALIDATION works or how to use it check:UJ_VALIDATION

So we found this problem regarding Delta Update on BW server.
After BW running on production phase for a couple days we saw the update are not running as they should. They’re some extraction that remain on yellow light. It seems like there are no data coming through anymore from ECC to BW side.

It turned out there are a lot of entries Queue-ing on ECC side. Using transaction SMQ1, we could see some entries are waiting in line to be extracted.

It’s like a ‘Clogged Pipes’.
So how do we overcome the clogged pipes? we need to take out the plug.
But, where is the plug in terms of data flow from ECC to BW?

What we don’t know is, there is a difference process to update Full/Initial Datasource and Delta Datasource. Full/Initial data extracted are store in Setup-Table.
If initialization is successfully extracted into BW PSA, delta generated on ECC. From then on, data collection stored in Delta Queue (RSA7) before extracted by Infopackage.

And now for the best part, Unclogging.
It turned out we need to do the V3 job, releasing the entries data delta into queue delta before delta info package is triggered from BW-side.
Go to LBWE.
By clicking the job control and scheduling the job. Data Entries that stuck on SMQ1 are flowing into Delta Queue RSA7.

After setting up the background job process( I think I need to create a blog post on how I do this) for every time delta infopackage requested, the ‘Clogged Pipes’ never seen anymore.