Remark: Updated April 3, 2019 with more generic information after cleaning up other transaction types and a brief revision of the content. 2 more cookies added to the jar.
I know, I know, many customers are already in 7.2, but there are still some that are not there, yet.
Greetings:
One of the realities you face in Solution Manager 7.2, is the fact that SAP introduced so many good new features to the SM* transaction types, that you want to incorporate them all into your ZM* transactions. The problem is that the incorporation of those changes via update, can only happen in your development system, because that is the system where the ZM* transactions were created, in principle. If a transaction type was not create in the system you are first testing the upgrade, e.g. a sandbox, you are left with only the option of working with the SM* transactions.
As upgrade times and deliverables are important, the more sophisticated or rooted you have your Solution Manager system in your organization, the more time it may take for your upgrade project. In that scenario, your organization may end up upgrading one or two sandboxes before you reach your development system. If that is the case, the present blogs gives you the opportunity of incorporating all the new SM* features into your ZM* transactions, for non-development systems, although you may still be able to take advantage of the approach explained below, in that system.
Objective: To show you how to use transaction AI_CRM_CPY_PROCTYPE to recreate your ZM* transactions.
Summary of how we achieve the objective: We use the copy option found in transaction AI_CRM_CPY_PROCTYPE. That transaction does not work immediately in your first try. We show you the steps to be able to perform a successful copy, by taking advantage of the very useful information the transaction itself provides. You will be able to identify the tables that need to be manually adjusted, and we will tell you the main methods to adjust them all.
The table entries that are to be manually deleted, can be approached with one or two the following 4 options:
It seems quite logical and obvious to undo configuration, but there are some tricks we explain below to overall achieve the goal.
Assumption: This blog assumes you are familiar with SPRO configuring ChaRM configuration, as well as using SM30/31. There are many steps we will go through quickly to make this document lighter. In that sense, when some tables are mentioned and we tell you to remove the records for an specific transaction type, e.g. via SM30, so you should know what we are talking about. Not a big deal taking special care, doesn't it?
Time for a cookie. Please take the first one from the jar.
The table that stores the transaction type information for the transaction types created in your SAP system is AIC_PTYPE_TABLOG. If a transaction type you are looking for has no entries in that table in the field PROCESSTYPE_TO, it means the transaction type was created in another system of your landscape and it came into the system you are checking via transport. This may give you a tip of why the update program does not work for you in a development system and no tables are retrieved when you press F4 in the selection screen below in transaction AI_CRM_CPY_PROCTYPE :
Process: We will take ZMCR for the exercise as that is the most challenging of all. For the rest of the transaction types, the process is very similar.
Step 1: Use the transaction AI_CRM_CPY_PROCTYPE to backup your transaction types, e.g. ZMCR > YMCR, ZMAD > YMAD, ZMHF > YMHF, ZMMJ > YMHJ. This will help if in the future you need a reference of how things were before you started the re-creation of the transaction types.
Step 2: Delete you transaction type ZMCR.
Via SPRO > IMG > SAP SolMan > Capabilities > ChaRM > Transactions > Multilevel Categorization > Assign Transaction Types to Catalog Categories.
Via SPRO > IMG > CRM > Transactions > Basic Settings > Define Item Category Determination.
Via SPRO > IMG > SAP SolMan > Capabilities > ChaRM > Transactions > Define Transaction Type.
Step 3. Use the copy program to try to see what else needs to be cleared. Unfortunately the step above leave lots of entries still in some tables, that need to be manually cleared.
Run the transaction AI_CRM_CPY_PROCTYPE to try to copy from the first time SMCR > ZMCR. You will get a first glance of the work to be done.
So, what do we have above? Two types of challenges. The yellow warnings (in red rectangles), refer to objects that are found still in the system and will not be overwritten by the copy. You can decide whether to incorporate the SM* changes or not into those tables, e.g. partner determination procedure. In our first approach, we decided to overwrite everything, so we had to go into each configuration area those yellow signs point to, to manually remove the configuration for ZMCR, in this case, via SPRO. We hope with this explanation is more than enough for you to know what to delete. You should know where in spro to delete: action profile, text determination procedure, etc. If you are not familiar my friend, either you are learning or you are in the wrong blog.
2 to 4 Tables that need to be cleaned via SE16, SM30/31, or maintenance view.
The clearing of the 13 tables in the blue squares is mandatory. Your mission is to clear all the entries referring to ZMCR in those tables, else the copy will not be feasible. As a final note, you may get a list of more or less tables with error status. Still the logic presented here can be used for your own reality.
***
Cookie #2. Before we show the analysis per table, one nice feature in the copy program happens when you double-click on an entry in error status. On the right hand side of the screen it will be displayed the entries the copy program is planning to insert. You can use that to focus on the entries you need to remove from that table, in particular. Example:
2. Example of a table which entries can be deleted via SE16.
For the table above CRMV_TRJN_TRCA you use SE16 to access it. Below the process:
After you do that, the table entries are displayed and after you switch to change mode, you will be able to clear the entries.
Step 4. Re-point current usage of ZMCR. Via SM30, update table DNOC_USERCFG by repointing the entries for ZMCR and ZSOLMANPRO to the standard.
Before:
After:
Note: After the copy, you will need to point back to ZMCR, even the newly introduced entry in 7.2 CHARM_ADD.
Step 5. Begin clearing up all the tables. The table below shows the tables from the copy report mentioned above reports, and the recommended method to clean up each respective table: Some via SE16, some via SM30/31, some via SPRO.
Note: Some of the SM30/31 tables could be accessed via SPRO, as well, but after a couple of searches with no results, we decided to take the quick path.
Note: Some notes about some of the tables above:
Create a function group via SE37 (Remark: Do not make the name longer than 14 characters).
Provide information similar to the one shown and save.
In transaction SE11 take a look at view SOCMV_PROC_TYPE2 and see the tables it is conformed of:
Proceed to create the new view (Remark: Do not make the name longer than 14 character ... even if you see below we used more than 14 characters. We are getting warnings in 7.2 SP08, we may have not got before).
In the screen below, you are supposed to select the fields for the maintenance view. For our case we leave them all there. You may want to activate now and may want to use a package related to the upgrade.
Assign the appropriate details, save and activate.
With that in place you should be able to use SM31 to access view ZTSOCM_PROC_TYPE to edit table TSOCM_PROC_TYPE and delete the only line left before you can actually copy SMCR on to ZMCR.
Cookie #3. As a general rule, table views that start with prefix SOCMV_, come with multi-screen maintenance view, which makes it almost impossible for this procedure to work, unless we start the cleaning in other order (not the approached taken here). Therefore you need to create the single screen maintenance views to bypass the challenge. Same need we found for view AICV_STAT_PROP.
Recommendation: You may not be a developer, so please do not rush, ask and follow your corporate naming convention for the developments. It is good that your work looks clean for future eyes looking at it.
Step 6. Copy process. Launch AI_CRM_CPY_PROCTYPE to copy from SMCR to ZMCR. The green light to copy should be visible. Screenshot from ZMMJ, another transaction type we were able to recreate
Step 7. Post-copy actions. Up to here, you have a vanilla transaction type. The pending actions are divided in 2:
With item #1, there are some important things to consider:
Note: Keep in mind, as of 7.2 Support Team has been replaced by Development Team.
With regards to Item #2, Web UI, same as it was done with the transaction types, you may want to backup the old configurations, delete the old ones and recreate them. Example ZMMJ:
With this in place, ZMCR is fully functional.
Step 8. Place back any additional SPRO customization performed in the past.
Step 9. Incorporate any pre-existing Web UI customization performed in the past.
Conclusion: We know, it seems like a long walk, but the satisfaction in our team was that we were able to fully access ZMCR in the sandbox to quantify the gaps we had, test security, etc. We were ahead of time in identifying all necessary steps for after the upgrade, before we reached the development system of the production landscape. That is not possible in the status quo right after the upgrade.
Hope you enjoy and thanks for reading.
Juan-Carlos Garcia-Garavito
Aftermath 1: If by any chance in your transaction type you need to add back customer user statuses and when you test them, one or more of them fail, go to transaction CRMC_ACTION_CONF, delete and insert the Action(s) that is(are) failing. You may have to add back again, e,g, scheduling entries. This should resolve that issue, which is originated due to an incomplete table cleanup.
I know, I know, many customers are already in 7.2, but there are still some that are not there, yet.
Greetings:
One of the realities you face in Solution Manager 7.2, is the fact that SAP introduced so many good new features to the SM* transaction types, that you want to incorporate them all into your ZM* transactions. The problem is that the incorporation of those changes via update, can only happen in your development system, because that is the system where the ZM* transactions were created, in principle. If a transaction type was not create in the system you are first testing the upgrade, e.g. a sandbox, you are left with only the option of working with the SM* transactions.
As upgrade times and deliverables are important, the more sophisticated or rooted you have your Solution Manager system in your organization, the more time it may take for your upgrade project. In that scenario, your organization may end up upgrading one or two sandboxes before you reach your development system. If that is the case, the present blogs gives you the opportunity of incorporating all the new SM* features into your ZM* transactions, for non-development systems, although you may still be able to take advantage of the approach explained below, in that system.
Objective: To show you how to use transaction AI_CRM_CPY_PROCTYPE to recreate your ZM* transactions.
Summary of how we achieve the objective: We use the copy option found in transaction AI_CRM_CPY_PROCTYPE. That transaction does not work immediately in your first try. We show you the steps to be able to perform a successful copy, by taking advantage of the very useful information the transaction itself provides. You will be able to identify the tables that need to be manually adjusted, and we will tell you the main methods to adjust them all.
The table entries that are to be manually deleted, can be approached with one or two the following 4 options:
- Using SPRO/IMG,
- Using SE16,
- Using SM30/31, or
- Creating a single screen table maintenance view.
It seems quite logical and obvious to undo configuration, but there are some tricks we explain below to overall achieve the goal.
Assumption: This blog assumes you are familiar with SPRO configuring ChaRM configuration, as well as using SM30/31. There are many steps we will go through quickly to make this document lighter. In that sense, when some tables are mentioned and we tell you to remove the records for an specific transaction type, e.g. via SM30, so you should know what we are talking about. Not a big deal taking special care, doesn't it?
Time for a cookie. Please take the first one from the jar.
The table that stores the transaction type information for the transaction types created in your SAP system is AIC_PTYPE_TABLOG. If a transaction type you are looking for has no entries in that table in the field PROCESSTYPE_TO, it means the transaction type was created in another system of your landscape and it came into the system you are checking via transport. This may give you a tip of why the update program does not work for you in a development system and no tables are retrieved when you press F4 in the selection screen below in transaction AI_CRM_CPY_PROCTYPE :
Process: We will take ZMCR for the exercise as that is the most challenging of all. For the rest of the transaction types, the process is very similar.
Step 1: Use the transaction AI_CRM_CPY_PROCTYPE to backup your transaction types, e.g. ZMCR > YMCR, ZMAD > YMAD, ZMHF > YMHF, ZMMJ > YMHJ. This will help if in the future you need a reference of how things were before you started the re-creation of the transaction types.
Step 2: Delete you transaction type ZMCR.
Via SPRO > IMG > SAP SolMan > Capabilities > ChaRM > Transactions > Multilevel Categorization > Assign Transaction Types to Catalog Categories.
Via SPRO > IMG > CRM > Transactions > Basic Settings > Define Item Category Determination.
Via SPRO > IMG > SAP SolMan > Capabilities > ChaRM > Transactions > Define Transaction Type.
Step 3. Use the copy program to try to see what else needs to be cleared. Unfortunately the step above leave lots of entries still in some tables, that need to be manually cleared.
Run the transaction AI_CRM_CPY_PROCTYPE to try to copy from the first time SMCR > ZMCR. You will get a first glance of the work to be done.
- Entries to be deleted via SPRO/IMG.
So, what do we have above? Two types of challenges. The yellow warnings (in red rectangles), refer to objects that are found still in the system and will not be overwritten by the copy. You can decide whether to incorporate the SM* changes or not into those tables, e.g. partner determination procedure. In our first approach, we decided to overwrite everything, so we had to go into each configuration area those yellow signs point to, to manually remove the configuration for ZMCR, in this case, via SPRO. We hope with this explanation is more than enough for you to know what to delete. You should know where in spro to delete: action profile, text determination procedure, etc. If you are not familiar my friend, either you are learning or you are in the wrong blog.
2 to 4 Tables that need to be cleaned via SE16, SM30/31, or maintenance view.
The clearing of the 13 tables in the blue squares is mandatory. Your mission is to clear all the entries referring to ZMCR in those tables, else the copy will not be feasible. As a final note, you may get a list of more or less tables with error status. Still the logic presented here can be used for your own reality.
***
Cookie #2. Before we show the analysis per table, one nice feature in the copy program happens when you double-click on an entry in error status. On the right hand side of the screen it will be displayed the entries the copy program is planning to insert. You can use that to focus on the entries you need to remove from that table, in particular. Example:
2. Example of a table which entries can be deleted via SE16.
For the table above CRMV_TRJN_TRCA you use SE16 to access it. Below the process:
After you do that, the table entries are displayed and after you switch to change mode, you will be able to clear the entries.
Step 4. Re-point current usage of ZMCR. Via SM30, update table DNOC_USERCFG by repointing the entries for ZMCR and ZSOLMANPRO to the standard.
Before:
After:
Note: After the copy, you will need to point back to ZMCR, even the newly introduced entry in 7.2 CHARM_ADD.
Step 5. Begin clearing up all the tables. The table below shows the tables from the copy report mentioned above reports, and the recommended method to clean up each respective table: Some via SE16, some via SM30/31, some via SPRO.
Note: Some of the SM30/31 tables could be accessed via SPRO, as well, but after a couple of searches with no results, we decided to take the quick path.
Note: Some notes about some of the tables above:
- The first entry is in light grey, as it is not really indicated by the copy report, but it is a pre-requisite for one of the tables below.
- For table CRMV_TRINB_PROCA, when you try to delete the entries for SOLMANPRO, instead of skipping the error that is displayed about not to change SAP entries, press <ENTER> and you will be able to delete the entries.
- The tables placed in italics and orange font only appeared when we decided to delete the partner determination procedure for ZMCR.
- Table SOCMV_STAT_PROP requires updates in two areas, one of them being a second table.
- The last table, the view in red font, SOCMV_PROC_TYPE2, was the real challenge. That view is formed by various tables, one of which is TSOCM_PTOC_TYPE. Unfortunately, there is no maintenance view built for that table. Without that maintenance view, you cannot delete the only entry left to get the green light to successfully copy SMCR > ZMCR. How did we achieve that?
Create a function group via SE37 (Remark: Do not make the name longer than 14 characters).
Provide information similar to the one shown and save.
In transaction SE11 take a look at view SOCMV_PROC_TYPE2 and see the tables it is conformed of:
Proceed to create the new view (Remark: Do not make the name longer than 14 character ... even if you see below we used more than 14 characters. We are getting warnings in 7.2 SP08, we may have not got before).
In the screen below, you are supposed to select the fields for the maintenance view. For our case we leave them all there. You may want to activate now and may want to use a package related to the upgrade.
Assign the appropriate details, save and activate.
With that in place you should be able to use SM31 to access view ZTSOCM_PROC_TYPE to edit table TSOCM_PROC_TYPE and delete the only line left before you can actually copy SMCR on to ZMCR.
Cookie #3. As a general rule, table views that start with prefix SOCMV_, come with multi-screen maintenance view, which makes it almost impossible for this procedure to work, unless we start the cleaning in other order (not the approached taken here). Therefore you need to create the single screen maintenance views to bypass the challenge. Same need we found for view AICV_STAT_PROP.
Recommendation: You may not be a developer, so please do not rush, ask and follow your corporate naming convention for the developments. It is good that your work looks clean for future eyes looking at it.
Step 6. Copy process. Launch AI_CRM_CPY_PROCTYPE to copy from SMCR to ZMCR. The green light to copy should be visible. Screenshot from ZMMJ, another transaction type we were able to recreate
Step 7. Post-copy actions. Up to here, you have a vanilla transaction type. The pending actions are divided in 2:
- The SPRO-based customization you had in ZMCR prior the copy that you will need to add back via SPRO or the new flavor of SOLMAN_SETUP.
- The Web UI, that also needs to go back to standard.
With item #1, there are some important things to consider:
- Via SM30, update table DNOC_USERCFG by repointing back the entries to ZMCR and ZSOLMANPRO. Check out the newly introduced parameter, as well.
- Restore back number range, approval procedure, and early numbering assignment, if applicable.
- In the partner determination procedure, you may need to adjust the main partners of your ZMCR. You can compare the screen below with the one your backed up when you created YMCR to bring back the old customization.
Note: Keep in mind, as of 7.2 Support Team has been replaced by Development Team.
- Also in Change Request Management Framework, review and compare between YMCR and ZMCR, Define status change depending on approval result.
- Compare YMCR and ZMCR via SE16 for table CRMV_TRINB_TRCA > SOLMAN-TRANSACTIONS.
- Are there are new texts in Text Determination Procedure that need to be incorporated.
- In multilevel categorization, are there business proposals to be adjusted?
- And the copy control, because the vanilla may have additional entries that are not required.
With regards to Item #2, Web UI, same as it was done with the transaction types, you may want to backup the old configurations, delete the old ones and recreate them. Example ZMMJ:
With this in place, ZMCR is fully functional.
Step 8. Place back any additional SPRO customization performed in the past.
Step 9. Incorporate any pre-existing Web UI customization performed in the past.
Conclusion: We know, it seems like a long walk, but the satisfaction in our team was that we were able to fully access ZMCR in the sandbox to quantify the gaps we had, test security, etc. We were ahead of time in identifying all necessary steps for after the upgrade, before we reached the development system of the production landscape. That is not possible in the status quo right after the upgrade.
Hope you enjoy and thanks for reading.
Juan-Carlos Garcia-Garavito
Aftermath 1: If by any chance in your transaction type you need to add back customer user statuses and when you test them, one or more of them fail, go to transaction CRMC_ACTION_CONF, delete and insert the Action(s) that is(are) failing. You may have to add back again, e,g, scheduling entries. This should resolve that issue, which is originated due to an incomplete table cleanup.
- SAP Managed Tags:
5 Comments
