Jump to content

Search the Community

Showing results for tags 'request import'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Hornbill Platform and Applications
    • OpenForWork
    • Announcements
    • Blog Article Discussions
    • General Non-Product Discussions
    • Application Beta Program
    • Collaboration
    • Employee Portal
    • Service Manager
    • IT Operations Management
    • Project Manager
    • Supplier Manager
    • Customer Manager
    • Document Manager
    • Timesheet Manager
    • Live Chat
    • Board Manager
    • Mobile Apps
    • System Administration
    • Integration Connectors, API & Webhooks
    • Performance Analytics
    • Hornbill Switch On & Implementation Questions
  • About the Forum
    • Announcements
    • Suggestions and Feedback
    • Problems and Questions
  • Gamers Club's Games
  • Gamers Club's LFT

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start








Website URL





Found 8 results

  1. We recently undertook an import of request form an ZenDesk service desk into Hornbill which all loaded correctly in to Hornbill, except for the active requests where the incorrect Service Level Agreements where assigned as the SLM Rules to determine the correct SLA to apply did not evaluate correctly. New request logged correctly since the migration directly in Hornbill do have the correct SLA applied using the rules in place. Our SLA rules use both the Organisation and Organisation Industry to determine which SLA to apply and as per best practice we have a default catch all rule to apply a default SLA. All the imported active requests got the default SLA. It appears the Organisation relationship used by the SLA rules is not being set properly by the import tool, so it is not able to evaluate the Organisation name or Organisation Industry values used in the rules. In terms of the imported requests these where matched at the user level by h_logon_id and also supplied the h_container_id of the organisation, using v1.8.1 of the tool. We have two concerns, One how to do we avoid this for future migrations, so that SLA rules apply properly? We have had previous issues in our instance where requests have subsequently become cross linked to the incorrect organisation due to different interpretations of the organisation and container id relationships, which has involved @Victor have to undertake corrections. Example SLA rule below Cheers Martyn
  2. @Steve G @Victor Is is possible to disable or bypass the Priority/Team/Category/Service/Catalog/Status Mapping on the Request Import tool? The reason for asking is that we do a loot of our mapping and data cleansing in the an interium database and already have the priority, service, status, catalog id mapped in the source data. However at the moment we have to add the values in the mapping to map the same to the same to get it to load. "StatusMapping": { "External Status": "Service Manager Status", "status.open": "status.open", "status.onHold": "status.onHold", "status.new": "status.new", "status.closed": "status.closed", "status.cancelled": "status.cancelled" } We would like to bypass the mapping and insert the values in from the source query. Cheers Martyn
  3. Can the Request Import Tool Error messages when decoding the json configuraiton file, be update to include the line number of the line the error occurs on in the file or some additional part of the text to make it easier to locate the error. Cheers Martyn
  4. When importing requests into Service Manager using the Request Import Tool, the requests are being matched to the correct organisation, with h_container_id and h_company_name being populated, but the h_org_id field is not populated with the link organisation id. The the application uses the container id for the link, we also use the organisation id as a field in some of our widgets to show top 5 logging organisations etc. Cheers Martyn
  5. Can I raise an enhancement to provide a Request Attachment Importer tool. Like the current SQL Request Import tool, provide a mechanism where the attachments information containing the case reference, visibility and file path can be queried form a database and the tool loads the attachments against the referenced requests. It it could also have the ability to match the case reference to a custom field/External Reference field, so that the source only has to have the legacy unique ID in it. Cheers Martyn
  6. We had an occurrence during a import load at the BPM Spawning stage where it overwhelmed our instance, causing http 502 response and the import process hanging. Would it be possible for the import tool to pause when it gets this type of error at this stage and await user input before retrying and continuing, to avoid having only partial BPM's spawned? 2019/03/22 14:07:18 [DEBUG] Spawning BPM [idox-open-objects-sr-slm] for [IDXSR00088697] 2019/03/22 14:07:18 [DEBUG] BPM Spawned: BPM20190322000769 2019/03/22 14:07:18 [ERROR] API Call Failed: Associate BPM to Request: Invalid HTTP Response: 502 2019/03/22 14:07:18 2019/03/22 14:07:18 [DEBUG] Spawning BPM [idox-open-objects-sr-slm] for [IDXSR00088698] 2019/03/22 14:07:18 [DEBUG] BPM Spawned: BPM20190322000770 2019/03/22 14:07:18 [ERROR] API Call Failed: Associate BPM to Request: Invalid HTTP Response: 502 Cheers Martyn
  7. Can the current Hornbill Request Import V1.2.0 be updated to include the following additional capabilities. Support the import and matching of Sub Status, only current supports parent status. Support the import and matching of Service Level Agreement and Service Level's. Extend current supported request types, Incident & Service Request, to include all other types, i.e. Change, Problem, Known Error and Release. Also as per the SQL Contact Import also support MySQL v8 connection with the new authentication method. Cheers Martyn
  8. As first indicated in my earlier post (link below), we are having issues with importing anymore than one request using the Hornbill Request Import v1.2.0. We have been testing with single rows, but now we have got to the stage were we want to test with increasing volume, the utility will only ever retrieve the first row from the RequestQuery table, irrespective of the where clause or even if you do not enter a where clause. The symptoms are as if the SQL is being run with the Limit 1 row setting. The secondary RequestHistoricUpdateQuery is retrieve successfully all the comment rows for 1 selected request row fine. We have also used the exact same database source for the DB2Hcontactimport v1.2.2 to insert over 3,000 contact records. Originally we where using a view as the source and I have created a physical table form the view, but the issue occurs for that as well. Environment is MySQL 5.7.24, as I downgraded from MySQL v8 which the tool does not yet support. Any ideas? Cheers Martyn
  • Create New...