In SAP the best run projects are the one’s that have been best scoped!
No one likes surprises and Change requests are fairly common in projects where the estimation wasn’t done correctly due to uncertainty in the initially scoped requirements or technical requirements which could have been pre-empted at an earlier stage and catered for in the budget.
SAP PO To BTP migration projects aren’t immune to such un-foreseen changes either but such changes can be reduced by a great margin by estimating the project right.
Let me start with an analogy of a house. If you have built a house or are going to build a house you often come across varying construction costs / quotes from different builders for strikingly similar designs, look and feel. House A might cost you 200k$ and House B 400$ and House C 600$.
One may ask what is the difference?
The difference lies in the inclusions offered in the house! I am not sure about other geographies but in Australia if someone is building a house they get quotes from different builders and then compare the inclusions (which sometimes go on for more than 20 -30 pages ) line by line.
RFP’s are quite similar where customers go through the features offered / assumed technical requirements and the cost and then decide the outcome. But what if neither you or the customer are aware of the missed requirements / gaps which should be addressed as part of the estimation? This results in change requests. (another reason being new requirements).
Coming back to the house analogy, the difference can also lie in
FeatureHouse A ($200k)House B ($400K)House C ($600k)FrameTimberSteelTimberSecurityNoneCCTV, AlarmNoneWater ConnectionNoneYesYesElectricityNoneYesNone
As you can see in the comparison above it doesn’t matter what the cost is, what matters more is – What is included! What is on the offer! What are the standard features being offered in the proposal.
House A – though cheaper would need multiple CR’s which will bring the cost up as its missing the technical requirements.
House B – Best Suited to the budget, fair pricing
House C – The builder has a office on wall street.
To avoid situations where projects overshoot their budgets its absolutely necessary to understand what are the salient features of robust integrations and what should be covered in good migration proposal.
SAP’s Migration Assessment Report – What is covered and What is not!
SAP’s migration assessment report clearly states that the estimates only include Technical migration efforts, To give you an idea of what they don’t include which should be and will be a part of the Migration see this comparison.
We will discuss these briefly but there are a few more things that you would never know if you haven’t done a few migrations yourself and I discovered these over the last few years.
1) That you really cant migrate your update_insert jdbc scenarios from SAP PO to Delete and Insert in SAP CI (batch) or even to update_insert that kills the performance. You have to rely on Stored Procedures.
2) For SELECT / UPDATE operations SAP CI jdbc adapter doesn’t behave in the same manner as SAP PO JDBC adapter. You do SELECT and UPDATE in different calls to the DB server and you run the risk of updating the flag for more entries than you selected again you should rely on stored procs.
3) Another interesting find was that SOAP RM adapter has a limit of 50k records both inbound and outbound which can be increased on request by SAP. therefore you should either limit your reports/ programs in SAP to select / push less than the number of records you have set for your tenant OR increase SAP CI Tenants record limit from 50K records per SOAP message to a really large number lets say 300k records but then run the risk of crossing the threshold of 100 mb message size which most of have (configurable) for outbound webservice / proxy message size sent via http out of S4.
4) You can convert your RFC/proxy scenarios to soamanager webservices (consumer proxies / service definitions) leaving IDOC scenarios as is.
5) For NFS scenarios you can either convert them to outbound async Webservices / XML or you can replace that NFS with a SFTP server.
6) Message Mappings: Don’t trust the SAP Migration tool blindly when it comes to Message mappings. Did you know that SAP Migration tool OVERWRITES the schema / WSDL file if the Message types in Source and Target structure have same name even if they belong to different SWCV?
Impact: The impact is that even if the names are same the structure is most of the times different and the message mapping basically gets corrupted and needs manual fix which is to export and import the source or target schema manually. Even if structures are same a misplaced namespace can cause the message to fail in SAP S4 or in third party system.
7) Migrating proxies to MDR: Do you know that proxies sometime or most of the time break as soon as you convert inline types to global types in ESR? This needs substantial manual effort Integration + ABAP if you have large number of proxies. always estimate that upfront.
SAP PO Migration tool converts Message types to XSD’s which are not editable in SAP CI – Graphically. Import your data types Message types separately if you need them.
9) Proxies vs SOAP RM : If you are doing a big bang and are running low on time proxy is fine, you can keep the XI adapters as XI, what this does is it forces the proxy connection to SAP CI over a single RFC destination, which is okay as long as you dont plan to run anything through SAP PO. BUT if you are doing a phased go live re-evaluate your approach as you would have to have SAP_PROXY_ESR pointed to SAP PO for the interfaces that get left behind and the only solution would be to have SOAP RM set up in soamanager and replace XI with SOAP RM which doesn’t take more than 5 minutes.
10) XSLT / UDF: It’s not just UDF’s that need to be rebuilt, a lot of time consultants use Dynamic Configuration in XSLT mappings which is kind of redundant in SAP CI, given we have properties but such XSLT’s almost never work in SAP CI and need modification.
11) SAP Migration tool inserts blank/empty exception handling subprocesses in each integration process for an iflow which is just a nuisance and serves no real purpose.
12) you cannot migrate a ICO with multiple operations in the ICO to SAP CI IFlow using the SAP Migration tool.
13) XPATH based routing conditions in SAP PO ICO dont work the same way in SAP CI, it might be CPATH version difference but I have seen it first hand, never trust the XPATH based conditions for receiver determination in SAP CI if it has not been tested properly.
14) XSLT Mappings dont work in SAP CI as is if you have dynamic configuration embedded into them
15) Migration tool should be capable of creating credentials in security store for scenarios where credentials are stored in the channel config in SAP PO but it’s not hence it’s an additional task that needs to be done.
16) migration tool shouldn’t convert the message types to WSDL’s as customers can now no longer maintain them graphically , SAP should either provide a functionality to modify the WSDL/XSD or should import the types as DDT and MT’s. The SI should import these to SAP CI in separate packages to avoid cluttering.
17) Be extra careful with BPM scenarios, Sometimes the ICO might look very simple and straight forward but you will in most of the cases have to re-deisgn the entire thing which may take days or weeks depending upon the complexity.
18) SI’s should take PO to BTP Migration as an opportunity to modernize Inbound and Outbound authentication mechanisms , like moving from Basic auth to Certificate Based Auth. If there is no restriction in terms of cost do not use SAP provided certificates for third party / Outbound cert based Authentication but get new CA signed certificates with a longer validity to spare yourself frequent downtimes.
19) Queues Queues and Queues! JMS queues are your best friend use them wherever they fit – asynchronous integrations.
20 ) Define a solid strategy for using your Dev SAP CI tenant as both a Test and Dev Tenant and for connecting to two / three systems.
21) Modularize re-usable parts of integrations and EXTERNALIZE your Parameters!
22) Approach third party systems/vendors on day 1 to avoid any delays later on and get a commitment and resources allocated for testing support.
23) Did you know that migrating aa proxy to MDR can take anywhere between 10 minute to 4 hours! Yes for a single proxy. For migrating a proxy to MDR you need to ensure that all the data types are global types and not inline types. Depending on the size of the schema it may take 10 minutes to 2 hours to convert the types and then surprise surprise! Your Re-generated proxy doesn’t work anymore! Wasn’t expecting that right. We then need to adjust the proxies and retest them thoroughly for an bugs.
As you can see a SAP Po to BTP Migration involves extensive planning and a very Strong Integration Architect to drive the transformation.
An SI should factor all these into the estimates and depending on the partner you are choosing the costs and the quality can vary a lot from vendor to vendor. Also It’s not only about the quality of build / processes that drives a transformation to success. The most important thing that’s often missed in such transformations is how approachable your team is and how much attention you are paying on building trust and how transparent you are.
Let me know your thoughts and if there are any learnings you came across worth capturing here.
In SAP the best run projects are the one’s that have been best scoped!No one likes surprises and Change requests are fairly common in projects where the estimation wasn’t done correctly due to uncertainty in the initially scoped requirements or technical requirements which could have been pre-empted at an earlier stage and catered for in the budget.SAP PO To BTP migration projects aren’t immune to such un-foreseen changes either but such changes can be reduced by a great margin by estimating the project right.Let me start with an analogy of a house. If you have built a house or are going to build a house you often come across varying construction costs / quotes from different builders for strikingly similar designs, look and feel. House A might cost you 200k$ and House B 400$ and House C 600$.One may ask what is the difference? The difference lies in the inclusions offered in the house! I am not sure about other geographies but in Australia if someone is building a house they get quotes from different builders and then compare the inclusions (which sometimes go on for more than 20 -30 pages ) line by line. RFP’s are quite similar where customers go through the features offered / assumed technical requirements and the cost and then decide the outcome. But what if neither you or the customer are aware of the missed requirements / gaps which should be addressed as part of the estimation? This results in change requests. (another reason being new requirements).Coming back to the house analogy, the difference can also lie in FeatureHouse A ($200k)House B ($400K)House C ($600k)FrameTimberSteelTimberSecurityNoneCCTV, AlarmNoneWater ConnectionNoneYesYesElectricityNoneYesNoneAs you can see in the comparison above it doesn’t matter what the cost is, what matters more is – What is included! What is on the offer! What are the standard features being offered in the proposal.House A – though cheaper would need multiple CR’s which will bring the cost up as its missing the technical requirements.House B – Best Suited to the budget, fair pricingHouse C – The builder has a office on wall street. To avoid situations where projects overshoot their budgets its absolutely necessary to understand what are the salient features of robust integrations and what should be covered in good migration proposal.SAP’s Migration Assessment Report – What is covered and What is not!SAP’s migration assessment report clearly states that the estimates only include Technical migration efforts, To give you an idea of what they don’t include which should be and will be a part of the Migration see this comparison.We will discuss these briefly but there are a few more things that you would never know if you haven’t done a few migrations yourself and I discovered these over the last few years.1) That you really cant migrate your update_insert jdbc scenarios from SAP PO to Delete and Insert in SAP CI (batch) or even to update_insert that kills the performance. You have to rely on Stored Procedures.2) For SELECT / UPDATE operations SAP CI jdbc adapter doesn’t behave in the same manner as SAP PO JDBC adapter. You do SELECT and UPDATE in different calls to the DB server and you run the risk of updating the flag for more entries than you selected again you should rely on stored procs.3) Another interesting find was that SOAP RM adapter has a limit of 50k records both inbound and outbound which can be increased on request by SAP. therefore you should either limit your reports/ programs in SAP to select / push less than the number of records you have set for your tenant OR increase SAP CI Tenants record limit from 50K records per SOAP message to a really large number lets say 300k records but then run the risk of crossing the threshold of 100 mb message size which most of have (configurable) for outbound webservice / proxy message size sent via http out of S4.4) You can convert your RFC/proxy scenarios to soamanager webservices (consumer proxies / service definitions) leaving IDOC scenarios as is. 5) For NFS scenarios you can either convert them to outbound async Webservices / XML or you can replace that NFS with a SFTP server.6) Message Mappings: Don’t trust the SAP Migration tool blindly when it comes to Message mappings. Did you know that SAP Migration tool OVERWRITES the schema / WSDL file if the Message types in Source and Target structure have same name even if they belong to different SWCV? Impact: The impact is that even if the names are same the structure is most of the times different and the message mapping basically gets corrupted and needs manual fix which is to export and import the source or target schema manually. Even if structures are same a misplaced namespace can cause the message to fail in SAP S4 or in third party system.7) Migrating proxies to MDR: Do you know that proxies sometime or most of the time break as soon as you convert inline types to global types in ESR? This needs substantial manual effort Integration + ABAP if you have large number of proxies. always estimate that upfront. SAP PO Migration tool converts Message types to XSD’s which are not editable in SAP CI – Graphically. Import your data types Message types separately if you need them.9) Proxies vs SOAP RM : If you are doing a big bang and are running low on time proxy is fine, you can keep the XI adapters as XI, what this does is it forces the proxy connection to SAP CI over a single RFC destination, which is okay as long as you dont plan to run anything through SAP PO. BUT if you are doing a phased go live re-evaluate your approach as you would have to have SAP_PROXY_ESR pointed to SAP PO for the interfaces that get left behind and the only solution would be to have SOAP RM set up in soamanager and replace XI with SOAP RM which doesn’t take more than 5 minutes.10) XSLT / UDF: It’s not just UDF’s that need to be rebuilt, a lot of time consultants use Dynamic Configuration in XSLT mappings which is kind of redundant in SAP CI, given we have properties but such XSLT’s almost never work in SAP CI and need modification.11) SAP Migration tool inserts blank/empty exception handling subprocesses in each integration process for an iflow which is just a nuisance and serves no real purpose.12) you cannot migrate a ICO with multiple operations in the ICO to SAP CI IFlow using the SAP Migration tool.13) XPATH based routing conditions in SAP PO ICO dont work the same way in SAP CI, it might be CPATH version difference but I have seen it first hand, never trust the XPATH based conditions for receiver determination in SAP CI if it has not been tested properly.14) XSLT Mappings dont work in SAP CI as is if you have dynamic configuration embedded into them15) Migration tool should be capable of creating credentials in security store for scenarios where credentials are stored in the channel config in SAP PO but it’s not hence it’s an additional task that needs to be done.16) migration tool shouldn’t convert the message types to WSDL’s as customers can now no longer maintain them graphically , SAP should either provide a functionality to modify the WSDL/XSD or should import the types as DDT and MT’s. The SI should import these to SAP CI in separate packages to avoid cluttering. 17) Be extra careful with BPM scenarios, Sometimes the ICO might look very simple and straight forward but you will in most of the cases have to re-deisgn the entire thing which may take days or weeks depending upon the complexity. 18) SI’s should take PO to BTP Migration as an opportunity to modernize Inbound and Outbound authentication mechanisms , like moving from Basic auth to Certificate Based Auth. If there is no restriction in terms of cost do not use SAP provided certificates for third party / Outbound cert based Authentication but get new CA signed certificates with a longer validity to spare yourself frequent downtimes.19) Queues Queues and Queues! JMS queues are your best friend use them wherever they fit – asynchronous integrations. 20 ) Define a solid strategy for using your Dev SAP CI tenant as both a Test and Dev Tenant and for connecting to two / three systems.21) Modularize re-usable parts of integrations and EXTERNALIZE your Parameters!22) Approach third party systems/vendors on day 1 to avoid any delays later on and get a commitment and resources allocated for testing support. 23) Did you know that migrating aa proxy to MDR can take anywhere between 10 minute to 4 hours! Yes for a single proxy. For migrating a proxy to MDR you need to ensure that all the data types are global types and not inline types. Depending on the size of the schema it may take 10 minutes to 2 hours to convert the types and then surprise surprise! Your Re-generated proxy doesn’t work anymore! Wasn’t expecting that right. We then need to adjust the proxies and retest them thoroughly for an bugs. As you can see a SAP Po to BTP Migration involves extensive planning and a very Strong Integration Architect to drive the transformation. An SI should factor all these into the estimates and depending on the partner you are choosing the costs and the quality can vary a lot from vendor to vendor. Also It’s not only about the quality of build / processes that drives a transformation to success. The most important thing that’s often missed in such transformations is how approachable your team is and how much attention you are paying on building trust and how transparent you are.Let me know your thoughts and if there are any learnings you came across worth capturing here. Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
