cancel
Showing results for 
Search instead for 
Did you mean: 

Copying data from an IBP Planning Area on one Tenant to the same Planning Area on another Tenant

Daphne_Froelich
Discoverer
0 Kudos

We use a three-tier architecture with three tenants (separate IBP instances) for Development, QA - User Acceptance Testing, and Production IBP. Each tenant carries a separate Planning Area for an individual division of our company, and we use Export from Dev, then Import and Forward through QA to Production to move configuration changes.

Problem: we have difficulty synchronizing the data (Master, Transactional, and "live user entries") between our three tenants to allow our developers and Power Users in the Non-Prod tenants to easily validate solutions or enhancements.

We cannot simply request SAP to perform a full data refresh from our Production tenant to a Non-Production tenant because:

  1. the refresh will overwrite all Planning Areas on the Non-Prod tenant
    ....a. At this time, Production only has one PA per division; but the Non-Prod tenants are also hosting PAs for projects in progress which would be lost / over-written
    ....b. PAs for ALL divisions will be updated... in general only one of our divisions is looking for fresh data
    ....c. we almost never have agreement between our divisions to take an outage to rebuild Dev or QA - all divisions have work in progress in separate PAs in all tenants at all times at varying degrees of completion
  2. the amount of time required to perform the refresh during which the Non-Prod tenant will be unavailable generally is not approved by the divisions using the application
  3. we use different security (different active users and different business role authorizations) in the three tenants - i.e. only developers and select Power Users can access Dev tenant; only select developers and select Power Users can access QA tenant (not necessarily the same as Dev users); and eventually we expect that no developers will be allowed access to Prod tenant
  4. the time and knowledge required to make adjustments to the refreshed tenant to adjust scheduled job runs, security, and other impactful configuration pulls key resources away from day-to-day operations support tasks

We have tried leveraging CI-DS (aka CPI-DS or HCI) to manually load the same data files that have been loaded to Production. Unfortunately this is an incomplete solution since we don't have anyway to capture the manual inputs and changes made by our PLMs, Planners, and Power Users each week and we don't currently have the same cycle of application jobs running in our Non-Prod tenants. So what happens is that we lose data generated by the business cycles occurring in Production; and without being sure of the underlying data relationships, random loads of specific attributes or bits of KF data without also keeping related attributes and KFs in sync eventually breaks the Planning Area. For example we want to test an IO Planning job - but we don't have the manually entered input data required to run the job in Development. This forces us to move un-tested changes to Production hoping we haven't missed anything in order to validate in Production.

Can anyone share their insights and solutions? Thank you, in advance!

Accepted Solutions (0)

Answers (1)

Answers (1)

lingaiahvanam
Active Contributor
0 Kudos

Hi,

The best practice approach is to maintain the data in each tenant combination of planning area.

Planning areas are subset of the divisions and different planning phases (ongoing projects), so it is business and implementation partner to evaluate the business requirements and project scope to define the harmonized data models across tenants.

We do have challenges to maintain the master/transactional data to support all business operations across the planning areas in all the tenants.

The ideal situation is built master/transactional data interfaces and application templates in development and rollout those to subsequent tenants, however it is manual activity.

I hope these notes will help you.

Best Regards,

Lingaiah