Maintenance Optimizer Setup for VARs

[richard_pietsch]

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,

Richard

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

[former_member190969]

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.

Regards

Andreas

[richard_pietsch]

Hi Andreas,

thanks a lot for your feedback. The usage of the proxy servers is a good point - we need to discuss this internally with the colleagues from basis department. Are there documents or guides available for such scenarios?

Regards,

Richard

[former_member190969]

HI Richard,

as far as I know there is no more than a PPT-slide showing customer and service provider connedted via two cascading proxy servers. If you have specific questionson this scenario please post them here so I can forward them to our experts.

Regards

Amdreas

[richard_pietsch]

Hi Andreas,

what do you think about the usage of the SAP Web Dispatcher in this scenario? As SLD data from JAVA data suppliers is sent via HTTP(S) I think this could be an option to centralize the communication. Also, for Web Dispatcher security options such as HTTPS or SSL can be used I think.

Regards,

Richard

[Former Member]

Hi Andreas,

belonging to this topic I have some more questions.

We have problems with the implementation of the MOPZ for our VAR customers too.

My questions are:

(1) As I know the SLD can't handle long SIDs. So if two or more customers have systems with the same SID and all these systems are connected via SLD to our VAR SolMan the data of the system which will be found first in SMSY will be overwritten several times. Is this correct? If yes, what will be the solution?

(2) How can we handle the xml-files? As I know, one of the created xml-files will not created new with every new maintenance transaction (in our case from different customers). Instead the information will be added to the existing xml-file. So we get a xml-file with data for different customers.

And of course an open item is, how should we provide acces to the xml-files for the different customers? They are stored in a directory on the VAR SolMan.

Thanks in advance!

Regards

Thomas

[former_member190969]

Hi Richard,

looking at the docu of SAP Web Dispatcher http://help.sap.com/saphelp_nw70ehp1/helpdata/en/48/8fe37933114e6fe10000000a421937/frameset.htm I guess that it can be used on the service provider side for incoming requests from customers. However it says "Outgoing requests are not sent via the SAP Web dispatcher. They are sent via the proxy server for the appropriate intranet." This means that the customer needs a cascading proxy server to get to the partner solman. If he doesn't I think it is not possible to control that only selected customers are able to get into the partner solman system. You need the proxies at the customer side if you want SAP Web Dispatcher to filter only those requests actually coming from your customers.

Forgive me if I am wrong in my assumptions. I am not really an expert in this web stuff, but still I am trying to help.

Regards

Andreas

[former_member190969]

Hi Thomas,

to your question (1): As I know the SLD can't handle long SIDs. So if two or more customers have systems with the same SID and all these systems are connected via SLD to our VAR SolMan the data of the system which will be found first in SMSY will be overwritten several times. Is this correct? If yes, what will be the solution?

This is not correct. SLD doesn't know SMSY long SIDs that's true, but it has it's own way of keeping different systems with same SID apart. It includes the message server of the system in the key. So in SLD data will be overwritten only if SID and message server of a system are equal, which is not very likely. When the data are transferred to SMSY it is important that the SMSY system knows this message server. This is no problem when all the systems are generated by landscape fetch job. When the systems have been generated from SAP Support Portal data as common in the VAR scenario, the message server is unknown. If it is an ABAP based system it will be mapped to the SMSY system correctly if it has the same installation number. If there are multiple systems in SMSY with same SID-Instno combination, the first one found will be updated. You check for those cases if you look at table AISYSNR_BUFFER in ALV-Grid display and sort it by SID INSNR. Then you can detect duplicates. For these cases you should maintain the message server manually in SMSY as well as for non ABAP systems. Table AISYSNR_BUFFER is filled by REFRESH_ADMIN_DATA_FROM_SUPPORT job from SAP Support Portal. This table is the source for the generation of systems in SMSY by this job. Unfortunately SLD does not yet read the SAP system number. So presently there is no 100% secure way to link a customer system to an SAP Support Portal system in all cases. If you have an SLD or RFC-link to a customer of yours and you have not yet created the customer systems by setting the corresponding flag in V_AISAPCUSTNOS, you should better let the Landscape Fetch job create your systems than the REFRESH_ADMIN_DATA_FROM_SUPPORT. The latter will then list all systems that can not uniquely be mapped to a SAP Support Portal system in the job log and you can do the correct mapping by selecting the right system number via value help on the tab "System Data in SAP Support Portal" in SMSY. By the way that is also the recommended in the IMG: The system generation in REFRESH_ADMIN_DATA_FROM_SUPPORT is always the last option and only good if you have no other connection to your customers system, no matter if you are a VAR or not. Also the IBASE is filled by the Landscape Fetch job for each new system as good as by REFRESH_ADMIN_DATA_FROM_SUPPORT.

Regards

Andreas

Edited by: Andreas Diebold on Aug 6, 2009 2:05 PM

[Former Member]

Hi Andreas,

thank you for your answer. Now it's much clearer for me.

Can you say something to my second question? Customer access to the xml-file....

Thomas

[former_member190969]

Hi Thomas,

I am sorry but I am not famliar with MOPZ. I asked some collegues for help but did not get any reply yet.

Regards

Andreas

[Former Member]

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.

Regards,

Dirk

[Former Member]

Hi,

check this [LINK|http://www.basisracing.com.ar/forum/viewthread.php?forum_id=17&thread_id=2&getfile=3]

Regards,

Srinu

[richard_pietsch]

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?

Regards,

Richard