Symptom
This Knowledge Base Article lists most of the frequently asked questions related to Business Configuration - Change Projects.
Environment
-
SAP Cloud for Customer
-
SAP Business ByDesign
Resolution
1. What is a Change Project?
After the milestone Go Live is executed, the active configuration is protected and configuration changes must be done in separate Change Projects. Changes done in Change Projects do not directly affect the tenant.
Change Project creation is possible after Implementation Project goes Live in Production tenant and Standalone tenant.
2. What are the Best Practices for Change Project?
- Keep Change Projects small in scope
- Keep Change Project lifetime short
- Never mix up Configuration Test Tenants with Add-On Development
- Cancel Change Projects that are not needed anymore
- Synchronize regularly with Production
- Regularly Simulate Merge
- Avoid mixture of Immediate Change and Change Project Changes for the same setting
3. When do I have to use Change Projects to make configuration changes?
After you passed the Go Live milestone in the configuration of your production tenant, Change Projects are necessary to change Scoping and Questions. For other changes, it depends on the actual setup. Immediate Changes are changes that can be done directly in the production tenant and will take immediate effect after save. Other changes require a Change Project.
4. Are there scoping options or questions that I can't change anymore after Go Live?
There are typically two situations in which you can't change options after Go Live:
- The option is set to protected or a protected option would be de-scoped when the option is changed. This is prevented by the system.
- The change of the option would result in the removal of some content (e.g. code values) that are protected by veto checks from the application, because there is business data that depends on it (uses it).
5. Can I do Immediate Changes while a Change Project is open?
Yes, both use separate storages. Your Immediate Changes will not automatically be part of the Change Project, you need to update your Change Project explicitly.
6. How can I update my Change Project with changes done in parallel in production tenant?
To update your open Change Project with changes you have already done as Immediate Change or via another Change Project in the productive Solution Profile, you can execute Update Project from Production to synchronize the changes into your Change Project.
7. Can I use multiple Change Projects in parallel?
Yes, but be careful. Technically there is no limitation, but our experience is that you increase your organizational complexity in your project if you split changes across multiple projects. Especially the changes are within one functional area, it is recommended in order not to lose control, to make them in a single change project. Again, there is no technical limitation, just our learning, that often changes relate to other changes and to make sure, the result is a consistent state, a close cooperation is required.
You can even move different Change Projects from the same production tenant into different Change Test Tenants and you can have local Change Projects parallel to remote ones.
8. How can I test whether the merge back of a Change Project will create a consistent situation?
Main function for that is to Simulate the merge. You can find the function in the Change Project's overview.
Note that the Merge Simulation can't simulate certain steps at the end of the Merge that are executed in the production tenant. Especially Veto Checks are not executed. Veto Checks check configuration changes against runtime data, especially in case a configuration entity is deleted. It will prevent the deletion, in case, business documents already exist that use that entity.
9. What is the difference between a local Change Project and a Change Project in a Test Tenant?
Local Change Project |
Change Project in Test Tenant |
|
Created |
In productive tenant |
|
Additional Test Tenant required |
No |
Yes |
Changes are immediately deployed (active in the system) |
No, only after Merge |
Yes, in the Test Tenant |
Where is the data of the Change Project |
In the Production Tenant |
In the Test Tenant |
What if I request a copy of my production tenant? |
The local Change Project is copied with the tenant. Of course, the local project in the copy points to the copy, not the original tenant. |
The change project is not copied (since it is in a different tenant) and still points to the original production tenant. The copy may show the remote Change Project in the list, but the connection is not functional. |
10. Can I move a Change Project into a Test Tenant, that has more PDI Solutions installed than the Production Tenant?
The set of PDI Solutions installed in the productive tenant (in which the Change Project is created) and the set of solutions in the Test Tenant (to which the Change Project should be moved) must be exactly the same (name and version of solution) at the following points in time:
-
When the Change Project is moved from Production to Test
-
When a Synchronize Project from Production should be performed
-
When a Merge Simulation should be performed
-
When the Merge Back is to be executed
At these points in time, the set of solutions is required to be equal. It is not required, that the set of installed solution is the same as at the beginning of the process: you can install a new solution after the Change Project is moved to the test tenant into the test tenant and configure it. Later when the Merge Back should be performed, the new solution should be present in the production tenant as well, so it must be deployed until then.
11. If I have a Change Project moved to a Test Tenant (for Merge Back), can I open another Change Project in this (Test) Tenant?
No, the Change Project is the main workspace and the Tenant is like a pre-production test tenant. This means: all changes are done directly in the main workspace and deployed immediately after save.
12. Can I compare changes in one Change Project with another Change Project?
No, this is currently not possible.
13. What are the basic preconditions that a ready Change Project can be merged?
First of all, the Change Project must be ready, this means, that all changes are done, verified, and tested and all Activities in the Activity List are closed, except the Merge and Close activities.
Then the Merge activity can be executed. It performs some basic checks at the beginning to check, whether the Merge can be done generally. These checks are checked with the Merge Simulation (see above) as well, so it is a good idea to perform this on a regular basis.
What is checked?
I - Is the productive Solution Profile locked?
A Solution Profile or Change Project is locked, if a user is currently working with it (changes something). Since only one can change it at the time - the user or the merge - the Merge will stop with an error, it detects a parallel user activity in the target Solution Profile.
II - Is another Merge still in process?
A Merge is not finished as long as activity Activate Solution Capabilities is not yet performed. This activity is typically present in change projects that changes some solution scope (scoping or questions part). If only fine tuning is changed, Activate Solution capabilities is not present. In order to perform a merge of another change project, the activity has to be performed before.
The activity will change the state of the change project to Activated. It is not necessary for a merge of a change project, that other change projects are closed.
III - Are the installed PDI Solutions are still the same?
This is only relevant for remote change projects. It is checked, that the PDI solutions of the test tenant and production tenant are still the same (name and version). If not, the merge will stop with an error.
14. Can I merge one Change Project (but not activate it), then create another one and merge this first before I activate both?
This is already answered in the question above: If on change project is merged but not yet completely activated, no other change project can be merged before. You must first activate the first change project and then you can merge the second.
After the merge (and before activation) of a change project you can create a new change project that contains all the changes from the first (because they are already merged in).
15. Is the Merge of a Change Project from a Test Tenant a two-step process?
Some people think that the merge from a test tenant is a two-step process: first the change project is moved back to the production tenant and then the merge is triggered once it is there. This is not true. The merge is a single step process and copying the change project back to the production tenant is part of it.
16. Does the Merge of a Change Project requires a System Downtime?
No, although the merge of a change project changes the configuration of a tenant, a downtime is not required. The implications of a configuration change in the related application depends on the nature of change and the application, typically even business users can continue with their job. Again, this depends on what is changed and how an application deals with it.
17. Are there Restrictions to Change Projects during the Release Upgrade Phase?
The Release Upgrade Phase is the time in which test systems are already upgraded to a new release version but productive systems are not. During this time, there are some implications on Business Configuration Change Projects, especially in case you use Change Test Tenants.
Local Change Projects
Since local change projects are in the same system as the related active solution profile, there is no special restriction to them. You need to know that changes in local change projects can't be tested and testing results from test tenants may not be valid since they are already on a higher release version.
Change Projects in Test Tenants
Change projects in test tenants are restricted during the Release Upgrade Phase, because the test tenant has already a higher release version than the productive tenant the change project refers to (should be merged into).
A Release Upgrade can upgrade a configuration (including change project) from a lower release version to the next higher release version, but not downgrade it. Therefore, there are restrictions compared to the typical way of handling change projects.
Don't try to merge a change project from a test system that has already a higher release version than the productive tenant you want to merge the change project into. Typically, the upgraded configuration (change project) from a higher version already contains elements that are not known to the lower version and they will make the merge fail when configuration is written back.
Moving a new change project from the production tenant into a test tenant that already has a higher version using Copy Solution Profile should be not a problem. The change project is automatically upgraded when imported. The merge back restriction from above still applies here, there is no difference whether the change project is moved to the tenant before or after the test tenant upgrade.
18. I have a productive tenant with open Change Projects that I want to copy into a new test tenant. What happens to the Change Projects?
This depends on the kind of Change Project, whether it is a local Change Project or a Change Project in a remote test tenant.
Local Change Projects
These projects are copied with the tenant and work in the copy the same way as in the original system. Once they are merged, the content is merged into the Solution Profile of the copy (not the original tenant the copy has been created on). If they are not needed in the copy, they can be canceled in the copy.
Remote Change Projects
Remote Change Projects that had been created before the copy of the tenant are moved to other tenants and a connection is maintained between the remote test tenant and the original tenant. A copy of the original tenant will not affect the Change Projects: they will stay in their tenants and still be connected to the original tenant.
In the copy of the tenant, the remote change projects are still visible in the project list as in the original tenant, but actually the connection is not functional in this tenant. Ideally, they should be hidden/removed from the list. This is currently not done automatically, it needs to be done in the backend. Please report a case to disable the projects.
19. Change Project in the test tenant remain in Merged status after closing the change project in Production tenant.
After merging a change project from test tenant to Production, the project should be closed separately in the test tenant because after merge there is no connection between tenants.
20. How to enable test tenant for remote change projects coming from the production system?
Please refer to KBA “2194540 - Unable to Close a First Implementation Project in Test System”.
21. When you merge a Change Project from Test to Production, will the merge overrite the Number Range changes from test to Production?
Yes, Any new/modification related to Scoping and fine tuning will be merged back.
22. Is it Possible to Change the Status of a Change Project from Canceled to Active from Frontend or Backend?
It is not possible to change the Status of a Canceled Change project.
23. Is it possible to copy a Solution Profile from a Test Tenant to another Test Tenant?
No. The only scenario supported is Production to Test. All other copies are not supported, such as Test to Test, or Test do Development.
24. When selecting Update changes from production, are settings removed that were only done in test system via immediate change??
Update changes from production takes over the changes made in production system into the test system. This should not remove settings made in the test system, unless these contradict the changes made in production and the production changes came later than the test changes. In case of conflicts, normally the conflict resolution screen should appear.
This is basically not depending on whether the changes in test system are made via the Overview screen or via Implementation Projects view in Business Configuration workcenter.
24. How to filter the Scoping Elements which have not been Reviewed?
To review the scoping elements, you may filter with the following steps:
- Go to Business Configuration
- Select Implementation Projects
- Select the Change Project
- Select Edit Project Scope
- Go to the 3rd phase Review Question
- Under the option My view, select Elements Not Reviewed
Expand the scoping elements, the Scoping Questions will be shown on the right side which needs to be reviewed.
25. Do the merge of Change Project, copy the Extension Fields through the change project?
Merging the change project will merge only the Scoping and Fine tuning, and no Flexibility data are copied
26. Is it possible to view the Active Scope of the Change Project before merging?
No. It is not possible to view the Active Scope of the Change Project without merging. It is mandatory to merge the change project to see the active scoping. The scoping questions are active in the change project and once merged with the main project, the changes can be seen by selecting the View Active Scope button.
27. At what point can you request a new Change Project to be sent to Test system?
A new project can be requested when there are no active project connecting the Source and Target tenant.
28. How can you check what changes were made as part of the Change Project that is not deployed?
It is not possible to check what changes were made as part of the Change Project when it is not deployed. Since the Change Project is not deployed and canceled, there would be no impact.
29. Is it possible to check who canceled the Change Project?
The change activity can be checked via backend. Please note, during Copy Solution Profile the Source tenant will be read only and any changes made to the Target tenant, the status would reflect in the Source tenant as well.
30.You have enabled the scoping question "Do you want to enable automatic locking of business users who have not logged-in in the last 90 days?" but it is still not working for some users:
You may have created a local change project to enable the scoping but the project is still not merged to the main work space. So changes are only available in the local change project. This selected Business Option will be active only when the change project is merged to the main WS and activated.
31. Is it possible to have seperate project in Production and Test tenant so that you dont have to merge from test to prod for every change projects
As per the standard process below are options you have,
1. Create a local change project in production and merge it back in Production itself.
2. Create a remote change project, where local change project is copied using Service Control Center process to test system.
If you want to work separately in test and production, then test tenant must be de-linked from production and make it standalone. However, you will lose the remote change project feature entirely, as test tenant is no longer connected to Production tenant. And test tenant will have main workspace, which can remain open and you can work with the main workspace as required.
And in the production tenant, you can only create local change project and merge it back to the main workspace. Please note, you will not be able to test any change project features, but only create and merge.
32.What is the difference between deployed on date and changed on date for a finetuning activity?
Deployment date- This is the date when the user performs an activity, such as opening an activity in the implementation project and changing fine tuning values. The date is recorded based on when the activity is carried out.
Changed on date- This is the date when the fine tuning activity is added to the project. It helps track when the activity was included in the project.
Keywords
frequently asked questions, business configuration, change project, remote change, test system, productive system, solution profile, , KBA , AP-RC-BCT , Business Config. Tools (SAP Business ByDesign , How To