I have done this with a couple of my clients, and a simple integration was relatively straightforward, however the more complex question is around the process you want to implement.

With the main client I worked with, they decided they wanted to more or less duplicate tickets in HP Service Manager with work items in RTC. This was really easily done using the HP Connect-IT synchronisation system. We just set up the RTC REST API on one side and HP Service Manager on the other side - it pulled the XML feed from RTC and let us map the fields between the two systems. Then each new HP ticket got pushed into RTC as a new Defect.

This completed the task but, as we had been saying to the client, it didn't solve the problem and really didn't achieve anything as far as a good process, but the client ticked the box and moved on.

To do this properly, you really need to define the goal you are trying to achieve. Once you know what you are trying to do, I have found that the answer with RTC/CLM and the OSLC REST API is always yes - I have now done this with 4 different Service Management systems from different vendors and I have never once had an issue on the Jazz side. On the other side we have had to do some pretty clunky things, but no matter what the SM side threw at us we always managed to get a good system working.

For HP Service Manager, the answer will involve using Connect IT to push things in each direction, and you will define a set of synchronisation rules to implement your desired process.

As a rough guide, the typical sort of workflow I have found to work well is:
 - problem tickets are opened in the SM tool. In a typical organisation these could be for anything from a broken seat to a server exploding!
 - the SM ticket is triaged by the Helpdesk team and most often closed with no need for any integration
 - if the problem is determined to be an issue that needs to go into RTC, the helpdesk operator will either flag the ticket via a field or will manually push a button to create a workitem. Typical work item types I have seen are Defects, Request for Enhancement, or a generic Issue or Change Request.
 - your integration will take key fields from the SM ticket (typically an ID, a URL or a way to get back to the SM ticket, a description, the application info and the SM operator ID or email) and create the work item in RTC using the REST API. Custom fields will need to be added to the work item to hold anything you can't map directly. I have done this push directly in some SM tools, via a scheduled synchroniser tool, or even via a shell script and an exported file attached to a button or a batch job within the SM system.
 - your integration will retrieve key fields from the work item (typically ID, URL, Owner, and State) and add them to the SM ticket in whatever way it can. Once again, custom fields will be added to the SM ticket to hold anything you can't map directly. The push can be through the synchroniser, or a batch job, or even a mail gateway where RTC sends the info as an email and the SM system picks it up.
 - the RTC team will then work on the problem as normal. They may use the SM ticket info stored in the work item to go back and see the details of the problem. Typically I have found that there's no need for comments and notes added to either system to be replicated, especially if you have a URL in both directions and you have the SM operator attached as a subscriber to the RTC work item.
 - at work item state changes, your integration uses the same push method to update the fields in the SM ticket as appropriate
 - when the RTC work item hits your Resolved state and is pushed to the SM system, you can use the change in RTC State on the SM side to flag the ticket for a call back to the client. Some SM systems can do this automatically, while others use a query to show all 'ready to close' tickets on a dashboard or some such.
- the SM operator finishes the ticket and your integration closes the corresponding RTC work item.

All this can be accomplished using a number of synchronisation rules triggered conditionally based on field values, and can be done in the tools, in an external synch tool, or even manually as a batch job. The hardest part I have always found is doing the SM side of the integration - the worst one I ever had to do was set up a custom email form in RTC, and trigger emails based on work item state changes. The email would go to a functional SM user account, which would import the email as it's own object, and then we had an update batch job that would run every 24 hours, look for new objects, change fields in the ticket based on the data, and then delete the object.

Hello  Davyd Norris,
Please let me know if you have solution architect for the integration and can be shareable.
Thanks

if the goal is to sync workitems between HP QC, then either RLIA standard or RLIA Tasktop can be used.  At this point my understanding is that these products will only sync the workitems.