Real life example of upgrading a 3-tier NetWeaver Gateway landscape

[Former Member]

Introduction

This blog shares our experience of upgrading a 3-tier NetWeaver Gateway landscape, pointing out the challenges we faced and how we were able to solve them.

Source Landscape

Existing 3-tier landscape with NetWeaver Gateway 2.00 SP 07 (NetWeaver 7.31 SP 09) in a central hub deployment model. Applications are connecting to a CRM 7.0 EHP1 system with NetWeaver Gateway 2.00 SP 07 backend components.

Target Landscape

Existing 3-tier landscape with SAP Gateway 7.40 SP 13 in a central hub deployment model. No changes to backend systems.

Upgrade Strategy

Execute a in-place upgrade. Start with sandbox systems, which are recent copies of respective production systems.

Initial Plan

According to SAP note 1830198 systems can be independently upgraded, upgrading Gateway doesn't require one to upgrade the backend components of the connected backend systems, assuming sufficient SP levels exist both in the Gateway and the backend systems. In our case we met the SP level requirements. The plan was not to upgrade the backend components.

Challenges

As soon as we had upgraded sandbox, we realized that our existing Gateway services didn't work anymore. More specifically, none of the services leveraging filter functionality worked. In addition there were issues with currencies that used to work that no longer worked.

Troubleshooting

Debugging the filter problem we found out that passing filter values got broken by the upgrade, values were being truncated. Looking into it in detail, we found SAP note 2205402 which we applied on both the Gateway system as well as the backend system, as instructed by the SAP note. This however wasn't sufficient. Since the corrections are partly contained in 740/13, we had to also implement SAP notes 2232883 and 2241188 on the Gateway system. Even that wasn't sufficient, we had to also implement SAP note 2245413 in the backend system.

Applying the SAP notes fixed the issues with filter functionality. The issue with currencies is explained in SAP note 2028852. We chose to change the applications in order to avoid the decimal problems described in the SAP note.

New Plan

In order to apply the SAP notes required to fix the issues with filtering, we had to also update the backend components to 2.00 SP 11. The new plan is to execute the in-place upgrade of NetWeaver Gateway and update the backend components.

Conclusion

I'm sure breaking compatibility or interoperability wasn't on SAP's radar but it happened. I have contacted SAP Gateway Product Management but I haven't yet been provided with an official explanation. In our case a simple technical upgrade of NetWeaver Gateway turned into a full-fledged upgrade project.

Takeaways

Take everything with a grain of salt, even official information can't be trusted. Test and validate everything yourself, preferably in a sandbox environment.

We are currently executing the new plan in our development landscape. I will update this blog should we run into other issues.

Update 4/6/16: due to lack of support from SAP and due to uncertainty of the solution, we decided to have a parallel landscape and upgrade that instead. Having Web Dispatchers in front of the Gateway systems allows us to point the applications either to the existing or the upgraded landscape without doing any changes to the applications.

Update 4/14/16: I'm not sure if it was because of how our Gateway landscape was initially built but generating a stack XML in MOPZ turned out to be a pain for the test system whereas there were no issues with the development system. According to SAP KBA 2043162, this was expected. We tried out Maintenance Planner and it seemed to work better than MOPZ in this context but we chose not to switch to MP in middle of the project and continued the MOPZ route. The problem we had in MOPZ was that the NetWeaver stack of the source constellation wasn't detected hence we were unable to upgrade from NetWeaver 7.31 to 7.40. In order to get the stack XML generated for the test system we had to use the stack copying tool RPT_MOPZ_COPY_STACK_XML.

Another issue we discovered while upgrading the test system was that we were no longer able to make changes to the existing services on an updated system and transport the changes to a system that hadn't been updated yet. Changing one of the existing services in the Gateway Service Builder (SEGW), building the service with IW_BEP 200 SP11 and transporting the request to a system with IW_BEP 200 SP07 resulted in syntax errors. One of the IW_BEP 200 SPs break compatibility with previous versions. The SPs change the type definition of ES_RESPONSE_CONTEXT for GET_ENTITY from /IWBEP/IF_MGW_APPL_SRV_RUNTIME=>TY_S_MGW_RESPONSE_CONTEXT to /IWBEP/IF_MGW_APPL_SRV_RUNTIME=>TY_S_MGW_RESPONSE_ENTITY_CNTXT. The latter is unknown to IW_BEP 200 SP07. We are currently blocked from making changes to any of the existing services until the upgrade has gone through all the way to production.

Update 4/21/16: we had to also install SAP note 2256525 to fix a bug where the length of data types was incorrectly calculated. In our case the bug occurred for a entity property of type Edm.String with Max. length of 6 which was mapped to a ABAP data type of CHAR with length 6. Without the SAP note, the system would incorrectly determine the length of the field to be 3. The bug caused filter selection options to be truncated.

Update 6/16/16: following successful testing and validation, we recently went live with the new upgraded Gateway landscape. No issues to report so far. To summarize, it was a rocky road and the entire upgrade took about 3 months longer than planned, due to the undocumented restrictions, bugs, problems and surprises we discovered along the way. My advice to anyone planning to upgrade their Gateway landscape is to setup a parallel landscape with reverse proxy configuration, plan to do development in both landscapes and expect having to update Gateway backend components as well as having to install SAP notes on both Gateway and backend. Also, do not underestimate the need for troubleshooting.