Skip to Content

SAP Solution Manager 7.2 architecture and migration to SAP HANA

This blog is based on the EXP session I gave at SAP TechED Barcelona. On request of SAP TechED attendees and community members who couldn’t be present at the session this blog post provides the information I have shared.

The week before SAP TechED Barcelona, I’ve spent a week at SAP Rot / SAP Walldorf to learn and discuss around SAP Solution Manager 7.2. Thanks to SAP for organizing this event to bring partners who focus on SAP Solution Manager up to date. You can find tweets and screenshots on twitter on hashtag #solman and #sapsoled2015. You can have a look at a condensed storify with screenshots here.

Product versions


Source: “Solution Manager roadmap”

SAP Solution Manager 7.1 will reach end of maintenance at 31/12/2017 due to the fact that the AS ABAP stack is running on an old SAP Netweaver version (7.0 EHP2) and the AS JAVA stack is using an old SAPJVM 4.1 version. Those old versions run out of maintenance so an upgrade is needed.

SAP Solution Manager 7.2 will run on SAP Netweaver 7.40 (both AS ABAP and AS JAVA) and has the capability to run on AnyDB (Sybase ASE, Oracle, MS SQL, …) or on SAP HANA. The CRM component goes from CRM 7.0 EHP1 to CRM 7.0 EHP3.

SAP HANA capabilities

SAP HANA can be placed under SAP Solution Manager 7.2 without the need for a SAP HANA license. Ofcourse customers still have to pay themselves for the appropriate hardware. This is a really nice incentive from SAP if you ask me. It can help introduce SAP HANA into organisations that do not yet run SAP HANA and provide the opportunity to get used to it. That way the organisation can prepare to support SAP HANA also for Business Suite and beyond.

It’s not yet an S/4 HANA like solution so the data structures are not yet simplified in scenarios that were already existing. It’s more like Suite on HANA if one would compare the current state of capabilities and what is leveraged out of the box to the ERP side of town.

This means SAP HANA brings data size reduction comparable to moving from ERP on AnyDB to SAP HANA which is somewhere between factor 4 and 10 (if the source database was uncompressed. Factor 4 is more common) depending on what kind of data is stored (unique entries versus recurring entries which can be compressed to a larger extent).

Further, you can leverage search capabilities of SAP HANA so customers who have a SAP TREX in place for SAP Solution Manager could simplify their landscape and no longer need to use SAP TREX for search capabilities.

In terms of speed, you’ll notice it most in reporting capabilities since that selects data rather than scenarios where lots of inserts take place. However, the non optimized embedded BW is still present so in the end the system doesn’t unleash SAP HANA performance out of the box. Lots of inserts (for example in Technical Monitoring) is typical for non optimized / simplified scenarios and therefor you won’t notice a big performance difference there.

So far, standard SAP scenario’s do not specifically require SAP HANA so you could also run on AnyDB (Sybase ASE, Oracle, MS SQL,…) without missing out on scenario’s and features at this point in time (SAP HANA specific scenario’s might be on the horizon though).

Celonis, a SAP HANA start-up has created a process mining application on top of SAP HANA. This can be leveraged by ITSM to check the process flow of incident tickets. This can help the customer identify where time is lost and where tickets are ping-ponged in between different teams. This can then lead to further optimizations of support provided. I didn’t get lots of details on this yet but I assume this does comes with a pricetag since it’s created by a start-up company and can be used on top of standard SAP

More scenario’s that leverage SAP HANA will come afterwards. SAP has also started work on a next generation SAP Solution Manager (S/4 HANA principals being applied to simplify data, do direct operational reporting, get rid of indexes etc). but that’s in a really early stage still.

Moving from SolMan 7.1 to SolMan 7.2 – technical

Upgrade using SUM / Dual Stack split using SWPM

From a technical point of view, an upgrade and dual stack split takes place. This means that you’ll end up with two SID’s, one for the AS ABAP part and one for the AS JAVA part.

What is AS JAVA still used for?

AS JAVA is still used by SolMan 7.2 for diagnostics agent connectivity and root cause analysis. In theory and probably also practice you could leave it out of the CHARM Solution Manager landscape if you’ve got two Solution Manager landscapes, one for Technical Monitoring and one for ITSM and CHARM which is not uncommon for large customers.

AS JAVA could also serve the purpose of local SLD for SAP Solution Manager although in general many administrators seem to prefer a central SLD nowadays with a higher Netweaver stack version and seperated maintenance cycles.

Sometimes AS JAVA of SAP Solution Manager is used for Adobe Document Services (ADS) to serve the ERP landscape. I’ve seen this mostly at smaller customers who do not create a seperate AS JAVA instance for that purpose.

Database options

When you look at the database you also have multiple options:

One database, with two schema’s, one schema for AS ABAP and one schema for AS JAVA where both have AS stacks their own SID or a dedicated database for each.

Moving to SAP HANA

When you also move to SAP HANA you perform an OS/DB migration (can be done using SUM DMO for the ABAP stack) and also here you have the above options available. In the HANA Enterprise Cloud (HEC) at SAP, most customers who have been testing SolMan 7.2 SP0 have AS ABAP running against SAP HANA and AS JAVA running against Sybase ASE. However, as noted in the previous “chapter”, you could run both instances against SAP HANA using a separate database schema.

Moving from SolMan 7.1 to SolMan 7.2 – functional

There are a lot of changes in SolMan 7.2 so this means SAP partners and customers need to have an understanding of these conceptual changes. These are discusses already in other blog posts and video’s that you can access through the SAP Solution Manager space on SCN.


Timing wise, SP1 is the first ramp-up version, SP2 is expected around March 2016 and SP3 (General Availability) around July 2016.

User experience


Source: “Solution Manager roadmap”

In SAP Solution Manager 7.1 there was a big mixture of different UI technologies: SAPgui, WebDynpro, Flash, Silverlight etc… Not exactly what one would expect or enjoy in general.

This has been improved a lot from what I was already able to access in SolMan 7.2. The start point for the end-user is Fiori launchpad. You’ll notice that you different functionality or scenario’s are available as tiles there.

Someone asked me the question how handy that really is and asked me what if you want to switch to an ABAP transaction? I found it enjoyable to work through Fiori launchpad and new UI’s. It felt rather refreshing. If you want to combine the ability of calling up ABAP transactions and accessing Fiori or SAPUI5 apps, you can leverage Business Client 6 which has just recently released and can handle multiple UI types in a single front-end client.

This new user experience also has some effects on the architecture. If you would also utilize SAP HANA specific applications (running on XS for example) and you would want to combine tiles you need a Web Dispatcher to dispatch to the correct application server.

Test drive SAP Solution Manager 7.2 in the cloud (coming soon)


SAP is planning to release an image of the SAP Solution Manager 7.2 ramp-up (SP1) to SAP Cloud Appliance Library (SAP CAL). This will allows customers / partners to test drive the different SP stacks of SAP Solution Manager 7.2 ramp-up versions (on SAP HANA even) in cloud environments that are provisioned through SAP CAL (Amazon AWS for example).

Another great initiative of SAP if you ask me, I personally very much like SAP CAL / Amazon AWS capabilities to test drive products of SAP. Expected delivery would be in December.

SAP Solution Manager and SAP Mentors

The SAP Mentors are SAP’s knights of the round table if you would express it in Camelot terms. We gather up around the table with SAP to discuss where SAP is going in all product area’s of SAP. SAP Mentors are elected through the community (by community members, SAP, SAP Mentors and externals even).

We’ve got really close connections to the SAP Solution Manager executives and teams so we continuously provide feedback and collaboration on new products and services. We also represent the community at large so we value SAP Community Network and welcome feedback from community members as well as other sources like User Groups. We notice trends through our engagements and bring those forward to SAP.

You must be Logged on to comment or reply to a post.
  • Hi Tom,

    thanks for the Info but i have one point where i highly disagree with you. The part about having two Solution Manager. One for Monitoring and one for ChaRM.

    Yes i know, some customers are doing this....and they aren't doing great with it.

    I really disagree with your statement even considering having two Solution Manager in a company Landscape!

    That's why we call it "Single Source of Truth".

    And separating Monitoring from ITSM? That is how you loose all your integrative features and how we can run out all our competitors.

    I am happy to discuss this with you 🙂

    Best regards


    • Hi, Thomas.

      Sometimes there is no other way. There are a lot of really very big companies that do not have connections between [DEV+TST+QUA+...] and PRD systems (ultra-super-high security requirements 😐 ). In such companies transports are exported from QUA and imported in PRD manually. So you have to use 2 SAP SM: one for monitoring of PRD systems and the other for projects, ITSM, ChaRM and etc...

      But I totally agree with you that when it is possible - companies should use one SM for everything.

      • Hi Artem,

        but those companies are not the regular type of customers. I also had customers which prefered the two SolMan solution. But they were never able to do a complete life cycle like you said.

        • Hi Thomas

          I wasn't putting out a generic statement that all customers should go run separated Solution Manager landscapes for different use-cases but it's reality. I was merely mentioning that some customers have their landscape set up like that.

          Those kind of customers (really big customers, MaxAttention customers in most cases) are the kind of customers where I thrive at the moment so I have to take it into account and I assume they are not the only one in the world who have this kind of setup.

          It comes with pro's and con's really. The advantage is that they can move one landscape faster (update more often to latest SP stack level) while in the other landscape they want to stick to the same version for a longer period of time (stability, wanted mostly in the ITSM / CHARM landscape).

          There can be other reasons still but this is one of the main reasons I've seen at customer side. They find that in order to keep their monitoring up to date, they have to patch too often and that impacts CHARM when CHARM is in place.

          So if SAP really wants customers to use one single source of truth, they have to tackle this point. SAP is aware of this in my opinion and is working on this by delivering content that resides in the cloud for example but only time will tell if SolMan 7.2 has what it takes to convince customers not to have dual landscapes.

          However, I won't be able to force customers to stick to a single landscape when they have good reasons not to do so.

          Not all customers run "the full lifecycle" or have a desire to do so. Many customers have other software in place that is used by the whole organisation so scenario's like IT Service Management and Change Management are frequently interfaced with external software.

          Technical Monitoring is often used in a complementary way, many customers still use other products to monitor their landscape so it might not be as critical as ITSM or CHARM.

          When a customer has no desire to couple Technical Monitoring to ITSM for example, why would a dual landscape be a problem? It costs money and maintenance effort but if the customer finds it's worth it and finds that it delivers added value then I don't see what the problem is really.

          Best regards


          • Hi Tom,

            completely understood your point of view 🙂 Fair enough, sometimes you have to adjust the design of a Solution Manager landscape.

            But still, i would not let count that argument with patching.

            If you apply SP Stacks, than you can do it every 3 months and from my experience an SP Stack is not really impacting ChaRM more than the monitoring. If it was impacted, it was already broken before.

            But i can guess what you mean...during a downtime ChaRM is not available but the monitoring is also not in available.

            And if they were my customers, i would not recommend to leave one SolMan on a different SP than the other one. That is not comparable to an ECC.

            And this is killing the advantage of the tool! Other vendors do have fancy tools, but we can offer a complete integrated tool

            We are going to tackle this point in recommending only one Solution Manager and not only following the customer opinion. Release 7.2 won't change the ways of working with Solution Manager, what should be changed? Patching? Patches still need to be applied, it doesn't make a difference if it's on premise or in the cloud.

            "it costs money and maintenance effort" - Exactly this is our starting point, we want to save money and lower the maintenance on customer side. Yes at a certain point in time, one has to admit that the customer won't change its behavioury, yes it is technically possible, but we still have to try to convince him to change.

            Best regards


          • Hi Thomas

            That's fair I think. The objective should be one Solution Manager landscape. Just saying that customers don't always listen, they figure things out on their own and if they think SAP is talking fairytails (figure of speak) they do what they think is best.


            CHARM wise, you have to test everything after patching. Customers won't go for "oh nothing much is impacted", nope, they test processes again after patching.

            Nothing much changes isn't exactly true either, otherwise there wouldn't be so many correction notes on the topic. Authorization objects have changed over SP stacks and that's just the tip of the iceberg. There is no way we can implement a stack without going through checking, testing etc.

            You won't convince me that CHARM is only impacted rarely because it has had a lot of changes if you look at the past already going from 7.1 SP4 --> SP12 lots of things happened and changed and new options became available etc. Ask Raquel Pereira da Cunha if you don't believe me 😉 . Customers tend to have custom code on top of CHARM because it cannot do everything they want it to do either so this is often also where impact is created when SP stacks are implemented.

            Customers that run heavy projects, don't want to have frequent changes on their Change Management implementation.

            Technical Monitoring

            While patching, customers are offered a narrowed down "Wily Introscope" monitoring as a replacement, not really what I would call "awesome".

            It would be great that one could switch all diagnostics agents to another SolMan during the patching and switch them back to the updated SolMan once patching is done for example.


            I think I could probably dedicate a whole blog post to ideas and thoughts of how things could be. I also know that SAP teams are working hard on the new versions of SolMan and it looks great, I've seen it, I've been able to test a little bit and it's an improvement, for sure.

            So if you ask me, it can be improved and it should be improved to convince customers to stick to a single SAP Solution Manager environment.

            7.2 won't bring major changes to the underlying infrastructure (unfortunately) ~ it would have been awesome if SAP would come with a totally overhauled SolMan running on HANA that takes full advantage of HANA but that's still in the far future. I know this is in the works, unfortunately SolMan is always running behind on things.

            Best regards


          • hello Tom,

            Regarding the installation on HANA DB, can you explain more regarding the architecture ?

            Do you realy need 4 different SID's ? 2 for JAVA + 2 for ABAP, 1 for HANA DB + 1 for application server for each instance ?


            Nissim Sraya

          • Hi Nissim Sraya

            It depends on your architecture, you can have one sid for AS JAVA, one sid for AS ABAP and one sid for HANA DB totalling 3 SID's given you would use a single HANA DB for both instances.

            I suppose you mean instance numbers instead of SID's? Yes, plenty of those.

            Best regards


    • Hi Vladimir

      Yes, that's correct, ST-ICO has been removed.

      A lot of content will be stored at SAP side in 7.2.

      So you'll find the content where it's appropriate (once that feature is available) ~ in this case I would assume you would be able to get content when you create a project (IT PPM based) which can be based on content provided by SAP.

      Best regards


  • Hi Tom,

    Thank you for the very detailed document. I'm interesting in following point of your document:

    Further, you can leverage search capabilities of SAP HANA so customers who have a SAP TREX in place for SAP Solution Manager could simplify their landscape and no longer need to use SAP TREX for search capabilities.

    Does this mean that if we don't want to install SM7.2 on SAP HANA we still should use TREX as we do it now? I mean that search engine is "integrated" only for HANA and not for other DBs.

    Thank you in advance for answer.



    • Hi Artem,

      Just thought I would share my experience so far..

      We have not installed 7.2 on HANA, and are currently planning our TREX installation, however you can use a HANA DB as the embedded search engine.

      In SOLMAN_SETUP > Process Management > Step 7 (SPS02) you define your search engine location:


      It is not required straight away, however to be able to define low-level authorisations, configure searching and enable re-use of created content, you need to be able to search via TREX or HANA I believe, based on what I have seen so far.

      • Thank you Andrew for the reply.

        We just think about the upgrade and lazy collect information about the procedure 🙂

        But the main point personally for me is whether I need to work on the message that is opened more than a 1,5 year on issue regarding TREX or to stop. So, if SolMan 7.2 provided the option to not install TREX for nonHANA DB I would stop working with the message and wait for that beautiful moment 🙂

        Once again - thank you for sharing your experience.



      • Hello Andrew,

        Regarding the installation on HANA DB, can you explain more regarding the architecture ?

        Do you realy need 4 different SID's ? 2 for JAVA + 2 for ABAP, 1 for HANA DB + 1 for application server for each instance ?


        Nissim Sraya

  • Hello Artem,

    If we understood correctly TREX installation is not Required if customer using HANA Database

    For other database like SQL server or Sybase  db2 etc we need to configure Trex



  • Hi I'm investigating a possible clean install of 7.2 On hana now its been released ?

    However i can't seem to access the hana installation media. Has SAP widely released it yet, for customers ?

    when filtering for hana DVD media MaxDB come up as a possibility ?

    Oracle seems fine, selecting ASE as a DB seems to list MaxDB as well !



    • Hi James

      I can see it so best to check with SAP probably then why you don't see it listed. SolMan 72 has gone GA.


      Best regards


  • Hi Tom

    No worries, that's the same number of items I can see. I was thinking SAP HANA its self would be available in the same way the oracle database is via these downloads.

    I can access SAP Hana Platform edition anyway from the SMP.

    I'm assuming a Sol Man Hana 7.2 installation is (Basically) the same as any other SAP Installation, prep the server, kick off SWPM, Select Solution Manager, Hana, run though the routine, then when installing the db, run the hana installation on the host.

  • Hi Tom

    I would like to know the best practice in terms of the architecture for SOLMAN 7.2 installation, MCOD or MCOS. Having two separate DBs for ABAP & JAVA, does it make the setup complicated than having one DB with two schemas.

    Thanks and best Regards

    Suwin K


    • Hi Suwin

      Recommendation from SAP is to go MCOD (when possible) because it makes configuration easier since it was like that and it stays like that.

      MCOS is also possible, it requires a bit more configuration.

      Best regards


  • Hi Tom,

    We have a Solution Manager system which we recently upgraded to 7.2 SPS4 running on Linux and DB6.

    We have around 250+ managed system connected to solution manager and almost all the ALM functionalities are being implemented and functional.

    Major ones are ChaRM, TechMon, BPMon, SOLDOC

    We also have custom reports developed for ChaRM and custom dashboards for OCC monitoring.

    We are thinking of migrating our DB from DB6 to HANA DB and from you blog I see it is possible and beneficial as well in:
    1. No need of TREX
    2. speed in reporting etc

    1. Having said we have almost all functionalities running what other major benefits we can get migrating to HANA DB
    2. Will the custom ChaRM reporting speed be imporved significantly
    3. What other features and functionalities can I use if we move to HANA like predective monitoring, or Focussed Run
    4. Are there any ready to use additional tools available which I can utilize post migrating to HANA DB

    Thank You


    • Hi Ajay

      1. Nothing much just yet. All features/functions currently have to run also on non-SAP HANA so without additional add-ons or something, functionality delivered by SAP, currently, doesn't have any special as far as I know. I've seen plans of introducing more intelligence based on SAP HANA but I'm not sure this will be delivered in standard. Most likely it can be additional (to be payed) add-on which makes the whole a different product (like Focused Build, Focused Insight, ...)
      2. /TMWFLOW/REPORTINGN is gone, instead the Search capability (running against TREX or SAP HANA) replaces this. If you run on SAP HANA, I would expect speed is good though.
      3. Focused solutions are seperate products. Focused Run in particular is a separate product that runs on a h igher SAP Netweaver level even and can only run on SAP HANA. So no you cannot do this if you run SolMan 7.2 on SAP HANA because it's in fact a different system in terms of components / versions.

      Focused Build and Focused Insights can run on regular SolMan 7.2 also as they are contained in a single add-on on top of SolMan 7.2

      4. Not sure what you mean by that last question. Follow the relevant guides from SAP to know which steps to execute.

      Best regards