When / how does push back of uCMDB ID to Service Manager happen?


We are populating data from Service Manager to uCMDB and pushing uCMDB ID's back to SM.

Chunk size is configured to 500 and we have over 12k CI's to import from SM on the integration job.

When / how does pushing back of uCMDB ID happen? From what we have seen, uCMDB is doing the following:

  • Import CI's in batch of 500
  • After every batch push back the uCMDB ID's for 500 CI's one by one (500 push requests) - even if uCMDB id has not changed
  • Import the next batch and repeat until all data is imported / IDs pushed back

On Probe server, discovery_probe.exe process is opening new TCP connection for every one of those uCMDB ID push back requests. Also on SM side we can see that hundreds of REST requests are coming to push back uCMDB IDs.

Is this a designed/wanted behaviour? Is there any configuration option available for SM adapter to handle this differently?




uCMDB 2018.11 using ServiceManagerEnhancedAdapter9-41

  • Unfortunately I haven't seen a good pushback implementation for any MicroFocus adapter - even the native UCMDB to RTSM is not working very well.

    Outside of that, the pushback should happen in a batch (ucmdbid_pushback.xsl describes it). if there is even one failure in the batch, the adapter will go pushback one by one. That's why you can decrease the batch size to be sure it will not fail so often.


    Petko Popadiyski

    Freelance Microfocus CMS UCMDB Consulting


  • Thanks for pointing out how push back should work.

    In our ucmdbid_pushback.xslt, If I'm interpreting it correctly, I see actually that the adapter is configured to push back IDs one by one.

    Is the content of your ucmdbid_pushback.xslt different than this:


    <xsl:stylesheet version="1.0" xmlns:xsl="<a href="">www.w3.org/.../Transform" target="_blank">">www.w3.org/.../a>" xmlns:ns="<a href="">http://schemas.hp.com/SM/7" target="_blank">">schemas.hp.com/.../a>"> <xsl:template match="/ucmdbIDPushBack/ci"> <model> <keys/> <instance> <xsl:for-each select="@id"> <ConfigurationItem><xsl:value-of select="."/></ConfigurationItem> </xsl:for-each> <xsl:for-each select="@ucmdbid"> <UcmdbID><xsl:value-of select="."/></UcmdbID> </xsl:for-each> </instance> </model> </xsl:template> </xsl:stylesheet>



  •  how did you conclude it is configured to do it one by one by reading this configuration? for-each takes each instance, but then puts them into a batch, configured in the sm.properties by calling "/ucmdbIDPushBack/ci"  SM service.


    Increase the debugging of the adapter so you can see every REST request and you will be able to validate what the adapter is doing in reality.



  • We can already see that seperate REST requests are sent to SM for every ucmdbID pushback. We can see TCP/IP connections being opened in hundreds from probe server for those push back requests.

    Also on SM side we can see those seperate REST requests, for pushback.


    Why uCMDB implemented the import in chunks but push-back with single requests, is beyond my comprehension and massive design failure.