Help with Custom Parameters for 'Sync Devices from SL1 to ServiceNow'
Hi all, I’m working on creating a schedule for the 'Sync Devices from SL1 to ServiceNow' application, and I’m trying to set up some custom parameters. Specifically, I want to configure custom settings for: - Include Org - Selected Device - Excluded Device I’ve written the code and tested it multiple times, but I’m having trouble getting it to work as expected. Has anyone successfully implemented custom parameters for these settings? Or is it even possible to override them with custom parameters in the current setup? Any help or guidance would be greatly appreciated! Thanks in advance!CMDB Sync relation overrides
Device sync has quite a mandatory configuration option about relations between SL1 devices vs Snow CIs. We have used that a lot but now struggling with some issue we noticed this "values" section. In documentation we can see this picture: which shows that there is part "values" and it is told that they are Additional Child Class Values. Then in example we have this { "cmdb_ci_db_mssql_instance": { "relations": [ { "parent": "cmdb_ci_win_server", "rel_type": "Runs on::Runs", "reverse": true } ], "values": {"sys_class_name": "snow_ci_class", "instance_name": "name"} }, "cmdb_ci_db_mssql_database": { "relations": [ { "parent": "cmdb_ci_db_mssql_instance", "rel_type": "Contains::Contained by", "reverse": false } ], "values": {"sys_class_name": "snow_ci_class", "database": "name"} }, "cmdb_ci_db_mssql_server": { "relations": [ { "parent": "cmdb_ci_win_server", "rel_type": "Runs on::Runs", "reverse": true } ], "values": {"sys_class_name": "snow_ci_class", "instance_name": "name"} } } Not much told about those in documentation, so few questions arise: when do we need to use those? Seems to be optional anyway. what are the field names to be used here. In the example snow_ci_class seems to be coming from device attributes/field from SL1, then probably the key part is the snow field? Is that correct?ServiceNow CMDB SyncPack v3.6.3 Release
Hello, We are pleased to announce the release of the ServiceNow CMDB SyncPack v3.6.3. This SyncPack addresses the following issues: Addressed an issue which prevented the interface sync GraphQL query from working if the SL1 AP2 version was 8.18.43-81 (JellyBean) or later. Addressed an issue that caused the device sync to fail due to the "EM71" region being overwritten. To address the issue, the "/api/v1/cache/dev-classes" API endpoint was updated to make the "default_dev_ class_id" and "servicenow_default_id" options configurable. You can download this and other SyncPacks from the Product Downloads > PowerPacks & SyncPacks tab on the Support portal. Please review the release notes for this SyncPack carefully before installing it. Thank you, Release ManagementServiceNow Service Graph Connector SyncPack v1.1.1 Release
Hello, We're pleased to announce the release of ServiceNow Service Graph Connector SyncPack v1.1.1. Issues Addressed The following issues are addressed in this release: Addressed an issue which prevented the interface sync GraphQL query from working if the SL1 AP2 version was JellyBean or later. Addressed an issue where devices merged in the Service Graph Connector with topology relationships caused an error. As part of the fix for this issue, a new enable_advanced_topology toggle was added to the device and interface syncs. The toggle is disabled by default. Additional System Requirements: "Base Steps" SyncPack version 1.5.5 or later. "ServiceNow Base" SyncPack version 3.8.0 or later. ServiceNow version Tokyo or later with Web Services enabled. ServiceNow CMDBCI Class Models version 1.49.0 or later. You can download the class models from the ServiceNow Store. "Service Graph Connector for ScienceLogic" application version 1.0.2. You can download the application from the ServiceNow Store. NOTE: The Service Graph Connector will not work with Incidents synced to ServiceNow. As a result, the Configuration Item field and the related list on the [Affected CIs] tab will not be populated when using the Service Graph Connector. The Device field on the Event record will also be blank. This issue is addressed in version 4.0.0 of the ServiceNow Incident SyncPack. You can find this SyncPack via the Product Downloads > PowerPacks & SyncPacks tab on the Support portal. Thank you, Release ManagementConnect with a PowerFlow Product Manager
We Want Your Insights! We would love to connect with you one-on-one to gather your feedback and insights about PowerFlow. Your experiences are key to shaping the future of our product! Why Chat? Share your thoughts on how we can improve Discuss any challenges you’ve faced Help us prioritize features that matter to you Please note that these calls are not intended to address issues that can be resolved through Support Cases. Ready to make an impact? Book a call with us now! Thanks for being part of our journey!ScienceLogic - ServiceNow Integrations: ITOM Licensing Requirements
ScienceLogic maximizes customers' investments in ServiceNow through its powerful suite of pre-built integrations, referred to as SyncPacks. ScienceLogic offers certified ServiceNow scoped applications for streamlined platform integration, accessible via the ServiceNow Store, ensuring seamless compatibility. Understanding the licensing requirements for ServiceNow integrations is crucial for informed decision-making. This document seeks to clarify the IT Operations Management (ITOM) licensing requirements for ScienceLogic integrations with ServiceNow. Its purpose is to eliminate any confusion regarding which integrations necessitate ITOM licensing. Note: ServiceNow’s ITOM licensing is further organized into different tiers. This document is not intended to help identify the suitable tier for your requirements. For any questions related to this, please contact ServiceNow. Scoped Application ServiceNow Module ITOM License requirement ScienceLogic SL1: Customer Service Management Integration Customer Service Management - Cases No ScienceLogic SL1: Incident Automation IT Service Management - Incident No ScienceLogic ServiceNow Integration IT Service Management - CMDB * Situational ScienceLogic SL1: Service Catalog Automation IT Service Management - Service Catalog ** Situational Service Graph Connector for ScienceLogic IT Operations Management - CMDB Yes ScienceLogic Event Integration IT Operations Management - Events Yes * ScienceLogic is actively adding support for cloud infrastructure mappings within our integrations. To effectively leverage these features in accordance with ServiceNow best practices, you might require ITOM licensing. Customers can contact their ScienceLogic representatives for cloud mapping questions. ** ITOM licenses are necessary only if you are implementing a CMDB using ITOM FAQs Here are some frequently asked questions (FAQs) from our customers Q: Are there other scenarios where one would need IT Operations Management (ITOM) licenses for CMDB? A: The necessity for ITOM licenses is primarily influenced by the specific goals of your organization. Customers of ScienceLogic are not required to adopt ITOM unless their integration module is inherently ITOM-based. We observe that customers generally opt for ITOM in the following situations: To deploy out-of-the-box ServiceNow automation for ensuring data quality and reliability. When transitioning to a more advanced, ServiceNow-defined CSDM (Common Service Data Model) framework. Q: Do Business Services in ScienceLogic need IT Operations Management (ITOM) licenses to be integrated into ServiceNow? A: No, it does not. ScienceLogic integrations leverage out-of-the-box ServiceNow CMDB tables, eliminating the need for ITOM licenses. You can effectively replicate ScienceLogic Business Service Models in ServiceNow by leveraging our integrations. Customer Testimonials Discover what our customers are saying about our integrations. “ We like that ScienceLogic has a tight integration with ServiceNow and particularly the fact that we don't need to deploy the additional discovery modules from an integration perspective. ” “ We are able to have a single pane of glass using ServiceNow. All monitoring events and CMDB population is managed by ServiceNow. ScienceLogic is a great monitoring system that integrates well with ServiceNow using its integration server, which provides workflow and rules that work with our systems. ”
Powerflow Application Queue Trigger Failure
Hi All, I've Developed a Runbook Action within ScienceLogic, that triggers a Powerflow Application if certain Runbook Automation Policy conditions are met. Upon execution, it sends the following payload: "params": { "configuration": configuration, "event_policy_name": EM7_VALUES['%_event_policy_name'], "event_details": EM7_VALUES, "organization_name": EM7_VALUES['%O'], "system_url": system_url, "queue": queue } These parameters are specified as inputs, and some are derived from the EM7Values. When the Runbook Automation linked to this Action executes against a specific Event Policy raised on a Device, i can see a success message in the "Event Notifications" window, and i can see all inputs and variables are passed through in its entirety. The real issue comes when you open Powerflow. The Application immediately fails, and an error message stating that theres an "Internal Request Error: pop from empty list". This error doesnt make any logical sense as the parameters i pass through are either JSON or String Payloads, no Arrays. I've been doing testing with the payloads, ensuring that the configuration being referenced exists, and confirmed all these are in place and are working fine. I then removed the "queue" value from the params body, and only passed the rest of the parameters, this succeeds and the application executes without incident. What's interesting, even if manually executing the application in the UI with a custom parameter set, as soon as you specify the queue, it fails. Now its important to know that we've only recently created the queues on a development system, and this is the first time we're testing with the newly created queues. I was hoping that someone in this community might be able to shed some light as to why this might be happening? Could it be that the queues are unreachable, and therefor when not specifying the custom queue, it defaults to the celery queue, which are reachable, and therefor works? If the queues are the problem, what could be done to try and fix the problem? Any and all contributions are welcome. Sincerely AndrePowerflow Application Immediate Failure
Hi All, I've Developed a Runbook Action within ScienceLogic, that triggers a Powerflow Application if certain Runbook Automation Policy conditions are met. Upon execution, it sends the following payload: "params": { "configuration": configuration, "event_policy_name": EM7_VALUES['%_event_policy_name'], "event_details": EM7_VALUES, "organization_name": EM7_VALUES['%O'], "system_url": system_url, "queue": queue } These parameters are specified as inputs, and some are derived from the EM7Values. When the Runbook Automation linked to this Action executes against a specific Event Policy raised on a Device, i can see a success message in the "Event Notifications" window, and i can see all inputs and variables are passed through in its entirety. The real issue comes when you open Powerflow. The Application immediately fails, giving no error and no explanation as to why it fails. I've been doing testing with the payloads, ensuring that the configuration being referenced exists, and confirmed all these are in place and are working fine. I then removed the "queue" value from the params body, and only passed the rest of the parameters, this succeeds and the application executes without incident. What's interesting, even if manually executing the application in the UI with a custom parameter set, as soon as you specify the queue, it fails. Now its important to know that we've only recently created the queues on a development system, and this is the first time we're testing with the newly created queues. I was hoping that someone in this community might be able to shed some light as to why this might be happening? Could it be that the queues are unreachable, and therefor when not specifying the custom queue, it defaults to the celery or 'priority.high' queue, which are reachable, and therefor works? If the queues are the problem, what could be done to try and fix the problem? Any and all contributions are welcome. Sincerely AndrePowerflow Application Immediate Failure
Hi All, I've Developed a Runbook Action within ScienceLogic, that triggers a Powerflow Application if certain Runbook Automation Policy conditions are met. Upon execution, it sends the following payload: "params": { "configuration": configuration, "event_policy_name": EM7_VALUES['%_event_policy_name'], "event_details": EM7_VALUES, "organization_name": EM7_VALUES['%O'], "system_url": system_url, "queue": queue } These parameters are specified as inputs, and some are derived from the EM7Values. When the Runbook Automation linked to this Action executes against a specific Event Policy raised on a Device, i can see a success message in the "Event Notifications" window, and i can see all inputs and variables are passed through in its entirety. The real issue comes when you open Powerflow. The Application immediately fails, giving no error and no explanation as to why it fails. I've been doing testing with the payloads, ensuring that the configuration being referenced exists, and confirmed all these are in place and are working fine. I then removed the "queue" value from the params body, and only passed the rest of the parameters, this succeeds and the application executes without incident. What's interesting, even if manually executing the application in the UI with a custom parameter set, as soon as you specify the queue, it fails. Now its important to know that we've only recently created the queues on a development system, and this is the first time we're testing with the newly created queues. I was hoping that someone in this community might be able to shed some light as to why this might be happening? Could it be that the queues are unreachable, and therefor when not specifying the custom queue, it defaults to the celery or 'priority.high' queue, which are reachable, and therefor works? If the queues are the problem, what could be done to try and fix the problem? Any and all contributions are welcome. Sincerely Andre
