Skip to Content

Maintenance Optimizer Setup for VARs

Hi everyone,

as VAR we take care of ~100 customers. Now, we are in the process of configuring our SolMan for the usage of the Maintenance Optimizer (MOPZ). However, there are a number of open issues we need to clarify before start. As I did not found sufficient information about these topics I thought you may have any ideasu2026

Issue 1 u2013 Source of data

The MOPZ is retrieving its source data from SMSY, which can be maintained either manually (not really an option for 100+x systems), via SAP Service Marketplace (correct/fully maintained?) or via System Landscape Directory. With each of these options we have some problemsu2026So here are my questions:

- For which scenarios I need which information in which detail? E.g. do I need detailed information on server, database, software component level when a new SP stack should be implemented? Isnu2019t this just relevant for EhP upgrades (to determine the delta between current-planned release)?

- How do I get this information best? SAP recommends the usage of SLD. Now, I guess, the problem will be that the VARu2019s customers are not willing to connect their network to the VARu2019s SolManu2026 Is there an option to have an external SLD at customer side connected with the VARu2019s SLD? (see also 2nd issue)

- Are JAVA components fully maintained via SAP Service Marketplace (maintain data for system)?

- From where the SLD get JAVA information?

- Is there an option to send data on server, database and software components from a SAP system to SAP Service Marketplace? As far as I know, the EWA is just adjusting already existing componentsu2026

Issue 2 u2013 Connections

Right now we have all customers connected site2site (router-router) and via VPN. SLD is using RFC/HTTP but this is not really an option due to security reasons.

- What other options are available to link these systems if a permanent connection or the link of the customeru2019s network to the VAR network is not desirable?

- Delta information from MOPZ are stored within a XML file (e.g. EhP upgrade) in SolMan as well as on customer side. If there is no connection... what to do?

The connection issue is also relevant for further functions such as the distribution of maintenance certificates, generating EWAs or the remote service delivery. Note, right now, there are no satellite systems. For the usage of the service desk the customers use a URL to the helpdesk.

Issue 3 u2013 double SIDs and components

- How are double SIDs (such as PRD or P01) for different customers handled in SMSY?

- Are these exceptional cases fetched when updating SMSY automatically?

- Is there a correct link to the corresponding JAVA components?

When maintaining the systems manually we could follow a naming convention.

I think the basic question is how we should connect our customers to the SolMan in a way that all security issues are covered and on the other hand communication is possible.

What do you think? Any ideas?

Thanks in advance,


Edited by: Richard Pietsch on Jul 13, 2009 3:39 PM

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • avatar image
    Former Member
    Jul 13, 2009 at 02:12 PM
    Add comment
    10|10000 characters needed characters exceeded

    • Hi Srinu,

      thanks for the link - I know the step by step configuration guide. But this is not the really point of my question.

      I will express my question in another way: for providing the functionalities MOPZ, maintenance certificate distribution, EWA monitoring, remote services is it absolutely necessary to have the VAR's customer systems connected via RFC (=satellite systems)?

      Are there other options possible? If yes, which one?



  • avatar image
    Former Member
    Jul 15, 2009 at 01:59 PM

    Hi Richard,

    well, I think that there is no other way than to link satellite systems via RFC to SolMan.

    The question is: in which other way could SolMan get data from satellite systems? In some cases, there are manual workarounds (like EWA download), but in large landscapes they are not usable in daily operation.

    Furthermore, SolMan himself is not multi-client capable (scope could be: one customer in one client), so if you face the challenge of not only connecting systems,, but granting access to customer users, you have to care about roles and profiles. And that is very time-consuming.

    We are evaluating the following scenario for MOPZ with one of our customers: access via workcenter for customer who is initiating a maintenance procedure. Basis team is doing the rest including implementation via SLM.

    Hope this helps you.



    Add comment
    10|10000 characters needed characters exceeded

  • Jul 17, 2009 at 06:56 AM

    Hi Richard,

    I am from Solman Development. Sending customer system software component versions to SAP and getting it back to the partner is not really an option since the only Way would be the old EWA directly from customer satelite system to SAP. But EWA does only do it for ABAP components and only productive systems. Also there it would be difficult to read these data from OSS and put them into SMSY since the data models of system data are quite different. That's the reason why our strategy is to get the data directly from customer to partner. A direct connection is also required for other scenarios anyway. We plan to enhance the creation of RFC connections via partner and customer router by generating them from SMSY including the routstring in EHP2. But for Non-ABAP the only option would be to connect SLD. Our network specialists told us that a secure option to connect SLD would be cascading proxies. These proxy servers would have the same routing purpose as the SAProuters in a SAPgui/RFC connection. So I wonder what are your concerns in this scenario? Please let us discuss them. We need to find a practible solution for the problem.

    By the way, when systems have the same SID they get created with different long SMSY-IDs. So this should not be an issue. An issue could be duplicate server names at different customers, but this is not relevant for MOPZ.



    Add comment
    10|10000 characters needed characters exceeded