SAP service desk is usually getting introduced in an environment in where an existing Third-party Service Desk is already in use.  Because of this, companies need to make a decision on how they will integrate SAP Service Desk with their existing Third-party Service Desk.

In this blog, I will describe Service Desk integration scenarios and DataXstream’s involvement in the Service Desk integration space.

Scenarios of how companies can introduce Solman Service Desk

There are many ways that Solman Service Desk can be integrated with other ticketing systems:

1. All tickets are managed in SAP Service Desk and existing ticketing system is retired
   • Easy for companies that don’t have an existing ticketing system
2. All tickets are managed in Third-Party Service Desk and SAP Service Desk is not used.
   • Easy for companies that don’t want to train and develop new processes
3. SAP Service Desk manages SAP related tickets and Third-Party Service desk manages general IT related tickets
   • Environment where it’s decided that the support is divided between SAP issues and General IT issues.
   • Integration between SAP service desk and Third-party Service is needed.  An SAP related ticket can be created in the Third-Party Service desk, Since it is an SAP related ticket, this ticket can be ‘sent’ over to SAP Service Desk for resolution or vice versa.
4. SAP Service Desk and Third-Party Service Desk both exist, but only want one Service Desk to contain all the tickets.
   • All of SAP Service Desk related tickets can be  synced over to the Third-Party Service desk ticket or vice versa.

Whatever the reason, many companies will need to integrate SAP Solution Manager Service Desk and a Third-Party Service desk.  Integration with SAP Service Desk is accomplished by being able to call the SAP Service Desk API’s.  These API’s can be exposed as WebServices that can be called by the Third-Party Service Desk.

DataXstream has made a conscious effort to make this integration as painless as possible.

How did DataXstream get involved in Service Desk of integration?

The following timeline highlights DataXstream’s involvement with SAP Solution Manager Service Desk integration:

• 2008: DataXstream was contracted by CA (formerly known as Computer Associates) to build a prototype to integrate SAP Solution Manager and CA Service Desk
• 2009: DataXstream was contracted by CA to turn the working prototype into a deployable product.  Multiple versions of the CA product were released from version 12.1 to 12.5
• 2011: DataXstream requested permission to CA to continue maintenance of existing installations and support and create a similar product.
• March 2011: DataXstream started development of a new Xstream Connector for CA Service Desk, an improved integration product, owned and maintained by DataXstream.

What’s Next?

DataXstream has decided to push forward with developing an improved Connector for CA Service Desk.

The following features included in Xstream Connector for CA Service Desk are new and/or improved over the standard SAP Solution Manager integration provided by CA Service Desk 12.5:

• Custom status mapping
• URL Linkage in Solution Manager ticket back to CA Service Desk
• Implementation of SAP enhancement framework to allow for interface customizations
• Enhanced ticket handling and resolution flexibility
• Real-time integration with non-blocking change propagation via Xstream Integration Broker
• Improved exception handling and logging
• Compatible with new and future implementations of CA Service Desk release 12.6
• Support for file attachments (available in future release)
• Ability to pass groups (available in future release)

Conclusion

With any new system that is introduced in a landscape, a decision will always need to be made about what to do with the current system that is in place.  By being able to integrate with SAP Service Desk API’s, offers flexibility to either keep or retire the existing Service Desk ticketing system.

How do you know when an Outbound IDoc has physically left SAP?

It’s a simple fact that if your subsystem never receives an IDoc from SAP, the subsystem will not be able to route or process the IDoc.   I have always gone by the notion that once the subsystem has successfully received the IDoc, the subsystem now has all the responsibility to process and route the IDoc, but before that time, SAP has the responsibility to ensure that the IDoc is fully dispatched.  The subsystem should have processes in place to determine if the IDoc has been received at the target system successfully or not.  In this blog I will focus on the handshake between SAP and the subsystem.  This will entail Outbound IDoc status and a couple of batch jobs that should be setup to ensure a better chance of a successful handoff between SAP and the subsystem.

First, let’s cover the normal, expected progression of statuses for outbound IDocs.  The following graphic shows the collection of status records for a random outbound IDoc.

The status records at the bottom of the list depict the IDoc status before the status records at the top of the list.  So, in this example, the IDoc started in status “01 – IDoc generated”, then progressed to status “30 – IDoc ready for dispatch (ALE service).”  These two statuses usually are created in rapid succession for outbound IDocs and mean that the IDoc has been created in the SAP system and is ready to be sent via tRFC to the subsystem.  The next two IDoc status, 03 and 12, can be a little confusing.  They both seem to mean that the IDoc has been dispatched from SAP.  What is the difference?  I have found that sometimes there is some confusion on weather the IDoc has left SAP or not.  After I explain the difference, I will show 2 batch jobs that should be setup in order to update the status if the Outbound IDoc has physically left SAP.

So what do statuses ‘03’ and ‘12’ really mean?

The status ‘03’ actually means “Data passed to port OK” which basically means that the IDoc has been dispatched to the tRFC queue and an attempt was made to send the IDoc to the subsystem.  However, that does not necessarily mean that the IDoc has left SAP.   There could be many reasons why SAP would fail to send the IDoc.  One example could be that the subsystem was down during the transmission of the IDoc.  Errors during data transmission would cause the IDoc to remain in the tRFC queue.  Thus, the IDoc would still remain in SAP and remain with a status of ‘03’.

When the Status changes to ‘12’; a successful connection was made to the subsystem and the IDoc was sent.  This status represents that the Outbound IDoc is no longer in the tRFC queue  and, therefore, has physically left SAP.  The IDoc is in the hands of the subsystem which is now responsible for processing or routing the IDoc.

But what if I never see a status of ‘12’ on IDocs that were successfully sent?

For one reason or another, sometimes the batch job to update the status to ‘12’ is not scheduled.  In Production this batch job is usually set up, however in the QA or Dev environment this may or may not be setup depending on the client.

1)  The following job should be setup in order to process a status ‘12’.  I typically set this to every 10 minutes depending on the client.

Program:  RBDMOIND – Schedule this program in order to check whether the IDoc have been successfully sent out of the tRFC queue.  If the IDoc has been sent successfully to the subsystem, the program RBDMOIND will change the status of the IDoc from status ‘03’ to status ‘12’.  This means that the handshake with subsystem was successfully and the IDoc has physically left SAP.

2)  There may be times when the subsystem is unavailable at the time the SAP is trying to send the Outbound IDoc.  By default, SAP will only make one attempt to transmit the IDoc.  By scheduling the following program in a batch job, SAP will try to resend the Outbound IDoc again at a specified time interval.  I also usually set this at job every 10 min, depending on the client.

Program:  RSARFCEX – Schedule this program in a batch job in order to resend any IDocs that have are stuck on the tRFC queue.

Ok I have set up these jobs, but the status does not change.  Now what?

Sometimes an Outbound IDoc could remain stuck on the tRFC queue and never get sent out successfully.  Some issues could be that the RFC Destination for the subsystem is configured incorrectly or there could be an authorization issue.  These types of errors need to be fixed before the batch job for RSARFCEX will send the IDoc out successfully.  You may need to get some additional detail of the problem.  Execute the following transaction below.

Transaction SM58 – This will check what is currently on the tRFC queue.   Once you display the list, you also have the ability to drill down and get some additional detail of what has caused the failed transmission.

Conclusion

Typically you won’t see many issues with Outbound IDocs.  From time to time, IDocs will get stuck on the tRFC queue and if not managed properly, could be stuck there a long time.  This blog should give you more visibility in respect to IDoc status to ensure that the Outbound IDoc has successfully left SAP for processing.

At one of my clients they had a requirement to run a batch job every 5 minutes.  Sometimes the batch job would take longer than 5 minutes to complete.  Thus, the same program would start in a new batch job before the previous batch job had time to finish.  The same program would collide with itself and cause issues.

It seems that SAP’s built-in job scheduler does not have a standard way of preventing overlapping job executions.  I was hoping to find a checkbox that would deny an execution of a job if it finds the same active job running, but that would be too easy.  However, SAP does have some different options in its toolbelt to satisfy this requirement.  The approach that I will demonstrate will use an event-driven approach to execute a SAP batch job.

First I will detail the High level overview of what needs to happen.  Then, after you understand the big picture, then I will go into more detail about how to code and configure this scenario.

High level Overview

Basically 2 SAP batch jobs are needed:

1) SAP Job #1

• This job will execute every 5min or so depending on your requirment and execute a simple custom program that will check the status of Job #2.
  • If the status of job Job #2 is not running, then the custom program will raise an event
  • If the status of Job #2 is running, then the custom program will do nothing

2) SAP Job #2

• This job is setup to start only when an event is raised
  • If an event is Raised from Job #1 then Job #2 will start.  Job #2 will contain the actual programs that you need to execute.

Sound easy enough?

Step-By-Step Instructions

Now let’s get to business and see what configuration and coding we need to do.

1)      First let’s define an Event.

Transaction SM64 – I defined my event as Z_JOB_START_XXXXX

2)     Next,  Create simple Custom program ZJOB_CREATE_EVENT to Raise the Event.   This program will basically check if the specified job is currently running.  If it is not running then Raise an event which was created in the previous step above.   In my case, I will  raise event ‘Z_JOB_START_XXXXX’.   Create a variant here with the Event Name(Z_JOB_START_XXXXX) and the Job #2 name (ZJOB_XXXXX).

3)      For Job #1.  Basically set this job as Periodic Time driven job to run every 5 minutes or so with the custom program ZJOB_CREATE_EVENT.  Also make sure you include the variant with the Job #2 name and Event.

4)      For Job #2.  Define this job as an Event Driven batch job and define the actual program (I used test program ZSPTEST) that needs to be executed.  Specify the event Z_JOB_START_XXXXX that this job will be waiting for.  Also checkbox ‘Periodic job’ to schedule another event job.

That’s it…Now the batch job will only execute if the same batch job is not running.

Testing

For testing purposes, I will demonstrate by manually execute program ZJOB_CREATE_EVENT to show that how this all works.

The event ZJOB_START_XXXXX has been raised by program ZJOB_CREATE_EVENT.  Now you can see the ZJOB_XXXXX is Active/Running

During the time the job is active, I attempted to execute program ZJOB_CREATE_EVENT again.   This time, the program knows that the job is still active and, therefore, it does not raise the event.  The only time the event will be raised again is once the job is finished .

This is only one scenario in where an event driven batch job is needed.  Now you can see how you can utilize an event driven batch job to put some control around how some programs are executed.

I will show how to configure and test the Web Service on ECC with Service pack 14 and higher.   Before Service Pack 14, the configuration is completed in ECC, however after SP14 the configuration is completed on the Java Stack.

Now let’s get started.

Execute the following transaction:
Transaction: SOAMANAGER

This will initiate a Web session and prompt you to log into the WebAS.
Once you have logged in, the next step is to locate the Enterprise Service that you created earlier.
To locate your Enterprise Service go to
Business Administrator Tab  –> Web Service Administration

First we will want to find the Enterprise Service that we created.   In our scenario, we named our test service as “ZTESTWEBSERVICE”.  After you have found your service, you need to display it by pressing the “Apply Selection” button.

This will display the current settings for this service.  Since we have not yet defined the configuration we will want to create a new service.  In the Configuration tab, select “Create Service”.

Enter a Service Name and a Binding name that you would like.  I usually put a prefix of “SN” and “BN” when defining a Service Name and a Binding name.

Here you will see all of the different type of runtime configuration options that are available.  As you can see you can configure other security and authentication options.  Once you are complete, press “SAVE”.

Now you are complete.  The Web Service should be up and running ready for an external application to call it.  Our next step is to obtain the wsdl location and execute a test a call to the Web Service from an external application..

Testing the Web Service

Before we can test the service we will first need to get the wsdl locations. With your service displayed,  go to the Overview tab.

Here you will want to click on “Open wsdl document for selected binding”

This will display the wsdl in another web session.  This is the URL that needs to be given to the external application that is initiating the call.  In our case, we will be using the WS Navigation tool to be doing this call.   Copy this URL.

Now we have the wsdl location, we will use the WS Navigator to perform the test.
In Overview tab, select the following link:
“Open Web Service navigator for selected binding”

Here you will enter the wsdl URL that you copied in the previous step.
Then press ‘Next’

Enter a valid user that will log into ECC when calling the Web Service

Now press ‘Test’.

Here is a list of available operations to call  this  Service.   Remember since we built it from just a function module it will only contain one operation.  If we want to build an service with multiple operation we would generate this service from a function group.

For this simple  example, the service will take any input and bring back a successful response.

And there you have it.  You know how to turn a function module into a Web Service and test the service with WS Navigator.

I have broken this down into 2 blogs
Part 1 will show how to create the simple structured web service
Part 2 will show how to configure and test the web service using SOAMANAGER and WSNAV

For this scenario, I created a really simple function module with one input and one output that will send back a response of “Response successful from test”   This will only create one operation for this service.  However, if you want to create multiple operations for a Service you can also generate the service from a function group.

You will need to ensure that the attribute is set as Remote-enabled in the function module.

Now go to transaction SE80 and right-click–>Create–>Web Service

Since SAP will be hosting this web service we will want to select  “Service Provider”

Select the radio button “Existing ABAP Object(Inside Out)”

Since we are building this web service from a Function Module.  The difference between and inside out vs. an outside is approach is where the structure is built.  From a design perspective, it is recommended that you use an Outside-in approach whenever possible.  This means that you would build out  the structure in the ESR and then implement the code behind it in SAP..  However, there will be cases when you will want to turn a Standard SAP remote enable function module into a Web Service, thus using this approach, the Inside out approach..)

Give a name to what you want to call your Enterprise service and specify that the endpoint will be a function module.

Enter the name of the Function module that the web service will call in the backend.

Here you will have to specify which authentication you want this service to have.  For this example I have set it to no authentication.

Now you are complete with building this web service.  However at this point you have just built the Web Service but you will now need to configure it so that an external application can call this web service.

This will come in my next Blog for configuring the newly created Web Service and as well as testing this  service.