Integrate > Integration Studio > How to Work with Data Push Jobs

How to Work with Data Push Jobs

This task explains how to schedule data push jobs and select the queries that are used to send data from the CMDB to another data repository.

This task includes the following steps:

  1. Create an integration point.

    Set up the integration to push the data from UCMDB. For details, see How to Set Up an Integration Point.

  2. Set Reconciliation priority.

    In the Integration Point pane, right-click the integration, and select Reconciliation Priority Manager from the shortcut menu. For more details, see Reconciliation Priority Window.

    Note For the data push jobs, the reconciliation priority should be done at the other end, on the target UCMDB server. By default all data push jobs have the datasource as UCMDB on the target server. If reconciliation priority is needed for the pushed CIs, then the datasource name should be changed. This can be achieved by performing the same steps from How to Add Reconciliation Priority for API-based Integrations.

    The dataStoreOrigin value set of the integration user can be used to set reconciliation priority for pushed CIs.

    In case more UCMDB datasources are pushing data to a same target server, then using several integration users with a different dataStoreOrigin value can differenciate the push datasources among them.

  3. Run the Data Push job.

    A scheduled data push job runs according to the scheduler setting; a live data push job runs when its TQL query result changes. For more information about live data push jobs, see Live Data Push Jobs.

    You can also run the integration manually at any time from the Integration Jobs pane. To do this, select the job, and then click one of the following buttons:

    • Full Synchronization : to synchronize all data for the first time.

    • Delta Synchronization : to synchronize only the data changes since the job last ran.

    For user interface details, see Integration Jobs Pane.

    Note  

    • If CIs in a data push job fail, the query is displayed in the Query Status tab as Completed with a warning symbol . You can drill down to see the errors that occurred and the CIs affected. This error data is saved in the system. When the job runs again to synchronize changes, UCMDB remembers the failed CIs and repushes these as well.

    • You can define a limit on the number sequential CI failures allowed during a running data push job. When this limit is reached, the job automatically stops running, enabling you to troubleshoot the reason for so many failures before waiting for the entire job to end.

      In the Administration module's Infrastructure Setting Manager, select Integration Settings and set the value of Maximum number of data push job failures allowed in a sequence. The default value for this setting is 20,000.

    • If, since the last synchronization, you have changed a TQL query (other than changes to conditions on existing nodes), all data is synchronized and the following message is written to the log: TQL was changed between syncs - performing Full sync!

    • High Availability environment: If a data push job is running, and the UCMDB Server responsible for write requests becomes unavailable or is changed, the data push job fails. You can wait for the next invocation of the job schedule, or alternatively rerun the data push job manually.

    • You can control the way the job handles null value attributes in the Adapter Configuration tab. For details, see Adapter Configuration Tab.

    • You can increase the number of threads for data push jobs. For details, see How to Increase the Number of Threads for Data Push Jobs.
    • You can run Delta Synchronization based on TQL query layout for data push jobs. For details, see xxx.

  4. Build a view of Data Push results.

    For details about viewing the data push results, see Working with Views in IT Universe Manager.

  5. View instances in IT Universe Manager.

    For details about viewing the CI instances, see Working with Views in IT Universe Manager.

Note In case of UCMDB being configured with Multi-Tenancy, this is the context in which the job is run and which may affect push job TQL result:

  1. When a user creates a push job, from now on the user will be the owner of it (the old push jobs will have no user). You can check the user from the JMX console (go to JMX console > UCMDB:service=URM Services, invoke the listResources JMX method by entering customer ID and Integration_PUSH_CONFIG as the resourceType value. On the returned result page, click the integration push job created, and then check the <created-by> tag). This user tenant may be used.
  2. When this push job is triggered via the Full Synchronization button from the UCMDB UI, it will be executed in the context of the logged in user. This means that, only the resources assigned to tenants of the logged in user will be pushed. (Similar for a Delta Synchronization)
  3. When a job is triggered via the scheduler, it will be executed only in the context of the sync job owner user, which created the sync job.
  4. If a job owner does not exist in case of scheduling, it will be executed in the context of the sysadmin user. (For example, for the old push jobs that have no user.)

  5. In case of scheduling, if the user that is the owner of a sync job does not exist, the push job will fail.

    In the ucmdb.synchronizer.log file, the following error will be logged:

    Caused by: java.lang.IllegalArgumentException: User with id {<userName>} does not exist

    The solution is to re-create the sync job or update the created_by tag of the sync job with an user that exists in UCMDB.

Related Topics Link IconRelated Information

Send Help Center feedback