The purpose of this document to explain the following
- Aspects of version controlling while creating/deploying a solution.
- Various scenarios related to the version controlling.
- Enable/Disable solution for a business user.
Thanks to my colleagues dpksghl, jayant.saini, bhupinder.sharma2, vaibhav.kwatra, kartik.saini as they have helped and contributed in preparation of this document.
Table of Contents
1. Version Controlling
It contains information and behavior of solution when it moves and gets deployed in another tenant either to production or test tenant, how this version management happens across tenants will get elaborated in this part of the document.
Find below the details of the few key points, we need to be knowing while controlling versions in C4C.
- Go to Administrator -> Implementation Manager
- Implementation manager contains 3 tabs, explained below:
Current version: It has below buttons available
- Assemble and Download :-
- Assemble and Download: - it will assemble this solution and will download so that we can move it to test tenant.
- Download a Copy: - it simply downloads the solution copy but generates a solution with different name, it can be used only for POC and backup purposes.
- Upload: - We can upload any downloaded solutions, mainly this option will be used in test tenant as we have to upload downloaded solution from development tenant.
- Activate: - Once we upload a solution it has to be activated in the test tenant, then only we will be able to create patch and work on that.
- Reactivate: - It will be only enabled in test tenant and can reactivate solution if first time it does not get activated successfully.
- Import Solution Template:-
- Refresh: - It refreshes the status and implementation manager window detail.
Version History: It contains the detail of solution version(s) currently created and uploaded. It also contains the sections that have error logs which appears during assembling or uploading solution, like sometimes if we try to upload a wrong solution it will throw error with appropriate details.
Tenant Status: It contains the current version details and solution status along with tenant details.
Find below the screenshot with implementation manager window details with solution having ‘BAC’ element and status in development.
Refer below screenshot with illustration of patch creation and movement of solution to test & production tenant:-
1.1 Sequential patch movement
In this type of movement,solution version movement happens sequentially,i.e. after moving V1,we work on V2 and move that in other tenant so on.
As illustrated below:-
- As described in basics of version controlling, Click on ‘Assemble and Download’ once development is ready to move to test tenant for testing.
- It shows one pop up saying once its assembled cannot make changes without creating patch of this solution , once pressed ‘OK’, it starts assembling and downloading the solution to local storage.
- We need to check in all the files of the solution by right clicking on the solution Check in all files before assembling and downloading the solution.
Refer the below screenshot:
- Assemble and download the solution after checking in solution files.
- Save it to Computer location, do not rename it as cloud studio uses this name to take care of versions when we upload this solution in test tenant.
- It saves the solution with solution name that will get uploaded in test tenant, it keeps name of solution different in different tenants.
- Once file gets downloaded, its detail gets updated in Implementation manager
- To move this solution into test tenant, open Implementation manager window and click on Upload below screen opens up
- Select the solution which we want to upload and click on Open.
- Once upload of solution into test tenant is done it shows the details in implementation manager, and asks to activate the solution so that we can create patch and work on this solution.
- Until we activate after uploading we will not be able to see any option enable on solution.
- Once we activate the solution by clicking ‘Activate’ button, it gets deployed and keeps the version 1 in the test tenant.
- We can test out our developments in test tenant.
- We can create patch of assembled solution in the development tenant to continue development and changes.
- It makes solution version 2.
- After making required changes we can assembled and download the solution and upload it.
- The same will reflect in the test tenant once we upload and Test tenant data will not lose on uploading patch solution.
Below is the screenshot where we added two entries in test tenant after uploading patch data remains there.
As shown in below screenshots,
- We created patch solutions in development tenant and currently 9th version is going on, and if we keep on uploading each and every patch solution in test then it will show the same details in version history of test tenant as well.
Version history in Dev tenant
Version history in Test tenant
1.2 Non-Sequential movement
In this type of solution movement to other tenants come into picture, when we want to skip sequential movement of solution, and want to release solution to test tenant after combined changes of few patches.
As shown below:-
Like in our example after first version movement to test tenant, we are directly moving patch of version 3 i.e. it will automatically take the changes done in patch of version 2.
Because after patch of version 2 only we can create patch with version 3.
So sometimes we create patch and does not want to move that straight forward to test tenant and want few additional changes In that case we can create another patch and once changes are done, can move that patch directly to test tenant and it will cover the changes done in patch 2nd as well.
Assembling and downloading version three as illustrated in below screenshots:
- Uploading version 3 and skipping of uploading version 2 to test tenant:
Version History in test tenant after version second upload
- After uploading version 3 it takes changes of patch version 2 as well and data remains there in test tenant:-
- ID2 field got added in patch of 2nd version and ID3 got added in patch of version 3rd.
1.3 Solution Movement Scenarios
In some scenarios if we are creating patches in the test tenant as well for bug fixes and parallel development is going on in development tenant in that case the version in the test tenant will be higher than the development tenant.
- Case 1(Solution is deployed and no patch is created):
In our example in test tenant we had uploaded version 3 and we are trying falling it back to version 2 by uploading the previously downloaded solution. It will show one pop up saying older version is already present it willcreate a patch with the name of original solution.
As shown below:-
On selecting ‘OK’, one solution patch will appear in solution explorer window with the same name as it is in development tenant having the version which we are trying to upload.
Refer below screenshot:
It shows patch of version 2 created in test tenant with original name, so if we work on this solution after activating and want to move to production it will create version 3 as this solution name is different.
- Case 2 (Solution and patch both exists):
When we have scenario where patches are being created in test tenant parallel to Dev tenant.
In that case if in test tenant version is higher than Dev tenant, on uploading lower version from Dev to test.
As shown below:-
In this case as test tenant will have 2 solutions one original and other is patch solution.
So while uploading it will ask in which solution we want to upload this solution from dev.
If we choose replacing patch solution it will go and check on which version it is running on.
And if patch solution version is lower it will upload it without any problem but if patch version is higher than the upload version, then it will throw error saying that the current version number exist so this version cannot be uploaded.
We are uploading 8th version but it says test tenant has 9th version of patch solution so 8th one cannot be uploaded.
In another scenario if we choose replacing original solution from the pop up that initially comes
It will check the same thing and correspond to the current version test tenant has, will throw either error message or will upload successfully.
In our example test tenant original solution version has version 7th and we are uploading 8th version so it will get updated successfully.
1.4 Enabling Solution/Patch for business user
Once we have deployed solution into test tenant, it creates one solution with different name, after activating and creating patch in test tenant, it creates patch with name of development solution name, and during this activity it disables this test original solution and enables the patch solution for further development.
Refer below screenshot:-
Original solution in test tenant
Patch created in test tenant
Whichever is enable in solution or patch in test tenant, will be visible in UI browser for business user to test out changes from either solution present in test tenant or patch changes.
Patch solution visible in work center for assignment
While initial creation of patch it automatically disables the original solution in test tenant and that will not be shown in work center assignment to business user.
After assigning patch work center to user, if we disable patch and enable original solution, it will make patch work center invalid and original solution work center will be visible for assignment to user.
Original solution visible for assignment
2. Appendix
Find below the table with list of the possible cases during solution movement and there corresponding behavior across tenants.
Movement of solution from development to test tenant
Detailed Illustration of Version Movement
- SAP Managed Tags:
6 Comments
