SAP Experts: VMware Virtualization | Consulting | Integration - DataXstream » SAP Basis

Discussing SAP SOLMAN Service Desk Integration Scenarios

Tim Cooper — Thu, 27 Oct 2011 14:30:58 +0000

When you purchase SAP ERP, you get SAP Solution Manager (SOLMAN) as part of the deal – ostensibly for free (although it is really included in the purchase price). SOLMAN provides a wealth of functionality to help manage the technical environment as well as project processes like testing.

Service Desk functionality is delivered as part of SOLMAN for use as a ticketing system. One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already. In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP. Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes, which obviously reduces the risk of transcription errors. And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management.

Here are some SAP Service Desk scenarios I’ve come across.

1. New SAP Installation

If you are a new SAP installation and have no ticketing in place Service Desk is a great place to start. As mentioned the functionality available allows end users to create tickets directly from SAP and have workflow set up to manage ownership and eventual resolution. Alternatively, a URL can be made available to allow trouble tickets to be logged via the SAP Service Desk web front end.

In this case end users and technical support personnel learn a new tool as part of their go-live experience.

2. Migrating Non-SAP System Support to SAP Service Desk

Rather than SAP being your sole IT application it is much more likely that you have an existing portfolio of systems and an associated ticketing tool and procedures for ticket management, escalation and resolution. A conservative approach when bringing up Service Desk is to use it initially only for SAP related tickets and deploy a limited set of functionality. This allows you to go through the growing pains and adjustments as you learn how to best make Service Desk work for you.

In the longer term migrating ticketing for non-SAP systems to Service Desk brings it all into one system. Using the Service Desk capability to create custom components and to build an organization structure that fully supports your users and systems facilitates consolidated reporting and the ability to monitor Service Level Agreements (SLA).

This approach works best if you have a fairly simple environment where the level of disruption is limited when decommissioning an existing ticketing. The impact on people, process and technology is carefully managed and the working environment has some tolerance for the time if and when things aren’t quite as expected at first.

3. SAP Service Desk Integration with an Existing Ticketing System

In situations where there is a well established ticketing system, it is unlikely that that system will be easily displaced by SAP Service Desk—and it may not make sense to do so. In this situation you can choose to not use Service Desk and forgo the system capabilities and instead use the existing ticketing tool to manage SAP issues. This gives up a lot of delivered SAP Service Desk capability.

Alternatively you can integrate the existing ticketing system and Service Desk and reap the benefits of both worlds. In this case you need to decide which system is the primary ticketing system and which is the secondary. DataXstream has worked with CA (formerly known as Computer Associates) to integrate the CA Service Desk offering with SAP Service Desk and now CA delivers a packaged solution for this integration.

3.1 SAP Service Desk is the Ticket Initiator

In the scenario where the SAP Service Desk (SAP SD) is primary tickets are initiated in SAP SD and categorized either as SAP related or as non-SAP related.

SAP related tickets are managed to resolution in SAP SD, including any communication with the SAP mother ship, and the secondary ticketing system, e.g. CASD, receives only informational updates on ticket progress, if required. The complete ticket lifecycle is managed and closed in SAP SD.

Non-SAP related tickets are transferred to the secondary ticketing system, e.g. CASD, where they are worked to their resolution. In this case ticket status changes and informational updates all occur in CASD and these updates are relayed to SAP SD.

In either case SAP SD and CASD can have a full picture of the ticket status throughout its lifecycle, the main difference being which system “owns” the ticket and has responsibility for working it and closing it out.

Overall the established ticketing system continues its original function and ticket resolution process, the key change being where a ticket is initially created.

3.2 SAP Service Desk is NOT the Ticket Initiator

In the scenario where SAP SD is the secondary ticketing system SAP-related incidents originate in the primary ticketing system, e.g. CASD, and are relayed to SAP SD. Now the SAP related incidents are worked in SAP SD where ticket information can be supplemented with all the SAP unique information that would be useful for analysis and investigation. Similar to the earlier scenario any significant status or informational updates in SAP SD are relayed to CASD and the ticket is ultimately closed out in SAP SD.

Any non-SAP related tickets are not sent from CASD, for example, to SAP SD.

Summary: A Natural Progression: from Island to Integration

SAP Service Desk can be deployed in a variety of ways in an organization: it can be a standalone ticketing and support system; it can be fully integrated with existing support applications. The role played and the pace of adoption is very flexible and is driven by an organization’s ability to manage the change and adopt new tools and procedures.

The general progression I have seen it to bring up SAP Service Desk as a standalone tool and then after a settling in period one of two things happens:

Existing ticketing tools and functionality are migrated into Service Desk
SAP Service Desk is integrated with another ticket management tool

In either case the outcome usually allows SAP related tickets to be created directly from SAP in order to capture as much detail as possible at the time of the incident.

SAP Solution Manager Service Desk Integration

Tim Cooper — Tue, 24 Aug 2010 14:15:58 +0000

Nowadays when you install SAP ECC 6.0 you get SAP Solution Manager (SOLMAN) as part of the deal – ostensibly for free (although it is really included in the purchase price). SOLMAN provides a wealth of functionality to help manage the technical environment as well as project processes like testing.

Service Desk functionality is delivered to you for use as a ticketing system. One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already. In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP. Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes which obviously reduces the risk of transcription errors. And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management.

Here are some SAP Service Desk scenarios I’ve come across.

New SAP Installation

In this case end users and technical support personnel learn a new tool as part of their go-live experience.

Migrating Non-SAP System Support to SAP Service Desk

SAP Service Desk Integration with an Existing Ticketing System

In situations where there is a well established ticketing system it is unlikely that that system will be easily displaced by SAP Service Desk and it may not make sense to do so. In this situation you can choose to not use Service Desk and forgo the system capabilities and instead use the existing ticketing tool to manage SAP issues. This gives up a lot of delivered SAP Service Desk capability.

SAP Service Desk is the Ticket Initiator

In the scenario where the SAP Service Desk (SAP SD) is primary tickets are initiated in SAP SD and categorized either as SAP related or as non-SAP related.

Overall the established ticketing system continues its original function and ticket resolution process, the key change being where a ticket is initially created.

SAP Service Desk is NOT the Ticket Initiator

Any non-SAP related tickets are not sent from CASD, for example, to SAP SD.

A Natural Progression: from Island to Integration

The general progression I have seen is to bring up SAP Service Desk as a standalone tool and then after a settling in period one of two things happens:

Existing ticketing tools and functionality are migrated into Service Desk
SAP Service Desk is integrated with another ticket management tool

In either case the outcome usually allows SAP related tickets to be created directly from SAP in order to capture as much detail as possible at the time of the incident.

Command Line Driven Transporting Using the ‘tp’ Command

Wess Tobler — Thu, 03 Dec 2009 05:00:18 +0000

STMS is a very powerful transaction in the BASIS world. The whole transport system in SAP is paramount to it’s functionality. 99% of the time, you will use STMS for your transport needs. What of that last 1%? Sometimes it becomes more efficient, or just safer, to have a little more manual control.

It is possible to add transport requests to the buffer, and even import them via the CLI (Command Line Interface). Keep in mind, whenever working on an instance at the OS level, you should be logged in as [sid]adm.

To add transports to the buffer:
tp addtobuffer [transport number] [SID] Client=[client number] pf=/usr/sap/trans/bin/TP_DOMAIN_[DOMAIN_SID].PFL

If I wanted to add transport number DV1K907046 to the buffer for Q01 client 400 and the transport domain controller was DV1 the string would look like this:
tp addtobuffer DV1K907046 Q01 Client=400 pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL

To import transports via CLI:
tp pf=/usr/sap/trans/bin/TP_DOMAIN_[DOMAIN_SID].PFL import [transport number] [SID] U128 client=400

Since I’ve added DV1K907046 to the buffer, I can now import it with this string:
tp pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL import DV1K907046 Q01 U128 client=400

It is also possible to create shell or batch scripts from these commands to do multiple transports at one time. I’ve found that this is when CLI tp management is most effective.
Using your favorite text editor, simply “stack” the commands ontop of each other:
tp addtobuffer DV1K907046 Q01 Client=400 pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL tp addtobuffer DV1K907047 Q01 Client=400 pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL tp addtobuffer DV1K907048 Q01 Client=400 pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL ....
Then save as either a .sh for Unix or .bat for Windows.

The batching approach works for both adding to the buffer and for actual import. It’s best to seperate each task (addtobuffer in one script, import in another).

Q2Q3Y6XJM37U

“Transporting” scheduled jobs

Wess Tobler — Mon, 07 Sep 2009 04:00:20 +0000

‘Transport’ is a touch misleading. In this example, we aren’t using STMS to move a job from one AS/CI to another, but we aren’t recreating it from scratch either.

Scenario:

Our SAP servers are running on HP-UX hosts with Oracle 10g databases. Recently, the client underwent SPS application to production servers. The process called for the stopping of scheduled jobs during update. The jobs were to be restarted as directed by team leads. When a request to restart job was executed, it was unable to be completed because the required job had “disappeared”. The job in this scenario was over 100 steps with different programs and variants being executed. Due to time constraints and the possibility of incorrect data entry, manually recreating the job in SM36 was not an option.

It is possible to extract a job definition directly out of the tables in which it is stored and then reinsert it into another instance (i.e. copy the job definition from your Q box and drop it back in Production). For demonstration purposes we will call our source server Q01 and our destination server P01. The job used in this example will be OUR_LOST_JOB.

NOTE: The steps used in this tip may utilize commands that access and modify data in ways not explicitly endorsed by SAP. Therefore, the use of this tip should be done at your own risk.

In Q01 verify that OUR_LOST_JOB is available by looking for it in SM37 or searching table TBTCP via SE16.
Log into the Q01 unix host as q01adm ( adm ).
Using your preferred text editor, create a file named ‘sm37exp.r3tr and enter the following statements adjusting entries to match your landscape:Export client=[source client] file=’SM37export’ select * from tbtco where JOBNAME=‘OUR_LOST_JOB’ select * from tbtci where JOBNAME=‘OUR_LOST_JOB’ select * from tbtcp where JOBNAME=‘OUR_LOST_JOB’ select * from tbtcs where JOBNAME=‘OUR_LOST_JOB’ select * from btcctl where JOBNAME=‘OUR_LOST_JOB’ select * from btcsev where JOBNAME=‘OUR_LOST_JOB’ select * from btcuev where JOBNAME=‘OUR_LOST_JOB’ select * from btcsed where JOBNAME=‘OUR_LOST_JOB’ select * from btcued where JOBNAME=‘OUR_LOST_JOB’ select * from btcevtjob where JOBNAME=‘OUR_LOST_JOB’ select * from btcdelay where JOBNAME=‘OUR_LOST_JOB’
As q01adm, execute the following command:
R3trans –u 8 –w sm37exp.log sm37exp.r3tr
This string creates the SM37export file which contains the actual job definitions, as well as sm37exp.log. Review the log to ensure a successful export (warnings are OK).
Copy the SM37export file to P01 p01adm home directory (/home/p01adm) and make sure to chmod 777 to grant full permissions.
Login to the P01 CI unix host as p01adm
Use your favored text editor to create the file ‘sm37imp.r3tr’ with the following contents:
import client=[destination client] file=’SM37export’ buffersync=yes
Execute the following command in /home/p01adm:
R3trans –u 8 –w sm37imp.log sm37imp.r3tr
Check the log to see if the import was successful
Log into P01 and search for OUR_LOST_JOB via SM37. It should be under status: Finished.
To recreate the job in “scheduled” status, execute menu “Job->copy”

The job has now been copied and is in status: “Scheduled”. From here you can either manually release the job or reschedule it for its proper frequency.

"Transporting" scheduled jobs

Wess Tobler — Mon, 07 Sep 2009 04:00:20 +0000

‘Transport’ is a touch misleading. In this example, we aren’t using STMS to move a job from one AS/CI to another, but we aren’t recreating it from scratch either.

Scenario:

NOTE: The steps used in this tip may utilize commands that access and modify data in ways not explicitly endorsed by SAP. Therefore, the use of this tip should be done at your own risk.

In Q01 verify that OUR_LOST_JOB is available by looking for it in SM37 or searching table TBTCP via SE16.
Log into the Q01 unix host as q01adm ( adm ).
Using your preferred text editor, create a file named ‘sm37exp.r3tr and enter the following statements adjusting entries to match your landscape:
Export client=[source client] file=’SM37export’ select * from tbtco where JOBNAME=‘OUR_LOST_JOB’ select * from tbtci where JOBNAME=‘OUR_LOST_JOB’ select * from tbtcp where JOBNAME=‘OUR_LOST_JOB’ select * from tbtcs where JOBNAME=‘OUR_LOST_JOB’ select * from btcctl where JOBNAME=‘OUR_LOST_JOB’ select * from btcsev where JOBNAME=‘OUR_LOST_JOB’ select * from btcuev where JOBNAME=‘OUR_LOST_JOB’ select * from btcsed where JOBNAME=‘OUR_LOST_JOB’ select * from btcued where JOBNAME=‘OUR_LOST_JOB’ select * from btcevtjob where JOBNAME=‘OUR_LOST_JOB’ select * from btcdelay where JOBNAME=‘OUR_LOST_JOB’
As q01adm, execute the following command:
R3trans –u 8 –w sm37exp.log sm37exp.r3tr
This string creates the SM37export file which contains the actual job definitions, as well as sm37exp.log. Review the log to ensure a successful export (warnings are OK).
Copy the SM37export file to P01 p01adm home directory (/home/p01adm) and make sure to chmod 777 to grant full permissions.
Login to the P01 CI unix host as p01adm
Use your favored text editor to create the file ‘sm37imp.r3tr’ with the following contents:
import client=[destination client] file=’SM37export’ buffersync=yes
Execute the following command in /home/p01adm:
R3trans –u 8 –w sm37imp.log sm37imp.r3tr
Check the log to see if the import was successful
Log into P01 and search for OUR_LOST_JOB via SM37. It should be under status: Finished.
To recreate the job in “scheduled” status, execute menu “Job->copy”

The job has now been copied and is in status: “Scheduled”. From here you can either manually release the job or reschedule it for its proper frequency.