Overview

Though standalone SAP Solution Manager offers heavy features & functionalities of Application Life Cycle Management and can handle an end to end cycle in Application Life Cycle Management, quite often, a scenario that’s most commonly asked by customers is that a 3rd party tool is already in place and they’re looking into capabilities of visualizing normalized data that’s been gathered by SAP Solution Manager in a tool they’ve already heavily invested in.

These 3rd party tools –

1. May be On-Premise or Cloud based;
2. May have standard adapters or not, to connect with SAP Solution Manager;

Irrespective of all these, once we are set to start integrating Solution Manager with a 3rd party Service Desk, there are few things that need to be considered, defined and agreed, so that project execution is smooth and the quality of delivery is high.

This blog is just to help someone out there, who’s going to work in an SAP SolMan ITSM Integration project and wants to know where to start and how to prepare. Of-course not all requisites are discussed here, but this will be enough to make a start. If anything is left out, please feel free to comment them.

Data to be replicated

This is obviously the most important of all, which is going to define the complexity of the project. What are the fields that need to be replicated? – Must be analysed and defined properly. Generally, fields like Description, Reporter, Support Team, Status, Priority, Category, Comments etc. can be replicated with ease. Challenges are in replicating data like SLA behavior, Audit trial based on timestamps of the tickets creation and updates etc.

List down these fields to be replicated, which will defining the scope of the project and building the logic later.

Data Availability

Is it going to be a unidirectional integration? (Data flows only from 3rd party to SAP always) or bidirectional integration? (Data flows to and fro between 3rd part and SAP always).

In either case, when the ticket is updated, how soon are you expecting the update to be visible in the other system defines the criteria for Data Availability.

It is required to understand that not all 3rd party Service Desks provide real time integration, therefore there will be delays in the updates to arrive into SAP. How long is it going to be? – Is something you must understand while defining the scope of the project itself.

SAP Solution Manager offers real-time outbound integration 🙂

Locking Mechanism

Where are tickets going to be handled? Are people going to use any one of the systems or both?

In case if a ticket is going to be actioned by people in both systems, how do you handle locks? (If a ticket is in Edit mode either in SAP or 3rd Party)

Discuss this with the 3rd party team and draft your logics accordingly, because if this is not considered in your logic, it is going to cause inconsistencies for sure.

Text Character Length limitations

Header Descriptions, Attachments Name, Business Partner Names, Categories, Status – Everything has a character length limitation in SAP Solution Manager. If your 3rd party tool supports longer character length, you are going to receive truncated data in SAP. Hence, consider this as well in the project.

HTML  Text Support

It must be understood that, default CRM UI of SAP Solution Manager doesn’t support HTML layout. Hence, sometimes, texts from 3rd party might look distorted. This can be resolved by enabling Rich Text format in Solution Manager.

Handling Attachments

Flow of Attachments – Unidirectional or Bidirectional?

How are attachments uploaded in 3rd party? (Screenshots, Comments, Description) – For a full fledged integration, attachments added everywhere must be brought into Solution Manager.

If the 3rd party supports uploading attachments onto multiple places in a ticket, then the complexity is high to accumulate them into the attachments assignment block in SAP Solution Manager.

Size limitations of data packets

Is there a limitation in the size of data packets transferred during the integration?

If yours is a real-time integration and 1000 tickets get updated with new attachments (2 Mb each) at the same, is your integration going to work still?

Understand these limitations and derive a handling mechanism.

Testing

This is due the point mentioned above. The load during testing would definitely be way lower than the actual business run-time. Hence, please plan for testing with near to similar load during the business run-time to test the integration properly.

Monitoring Mechanism

There must be a monitoring mechanism built to;

1. Monitor the integration
2. Identify data lost and reprocess them
3. Make sure the integration is working fine

Downtime Management

What happens during a planned/unplanned downtime of any one of the systems involved in the integration? This must be considered and tested, so that there are no data loss due to down times.

Conclusion

These are few points from my experiences in Integration projects. Since every integration project is different, solutions to all the above discussed points vary, which is why, I haven’t discussed any solutions here. This is just to provide ideas to anyone who’s working in a 3rd part service desk integration project.

Please feel free to post your opinions on this & comments to improve this blog.