Device configuration "key/value" pairs synchronization to ITSM
With Powerflow most data are pretty easy to sync from SL1 to ITSM/CMDB, in this case ServiceNow. But now we have requirement that we should sync cloud device tags from SL1 to SN. The data from Azure virtual server, using Azure PP, is shown on SL1 like below, multiple key/value rows per device. So those are not easily stored into Attributes. And if I have understood correctly, quite a lot of tags used in cloud. Any ideas how these could be synced with PF into ServiceNow?Solved281Views1like8CommentsWho will be our next SL1 Innovators?
Hello Nexus Members, Looking to showcase your creativity, innovation, and inspiration? Look no further. In case you're opted out of email, we just launched our SL Innovators Awards!! Our ScienceLogic Innovators Awards were established to recognize and learn from those nerdy by nature, tech buffs, and visionaries using SL1 in pioneering ways to power a better way to work. Show the Nexus Community something cool and innovative you've been working on to achieve real business outcomes. We want to hear your ideas! Submit your application by September 12.47Views0likes0Comments2024 Customer Success Honoree Award Winners
Any community whether online or in person is a place to share and learn. As leader of Customer Advocacy, my role too encompasses sharing the voice of our customer in many formats in order for our peers to thrive from this knowledge. In case you missed it, we recently launched our ScienceLogic 2024 Customer Success Honorees - an awards program recognizing those who have made significant progress in a specific area, and have been an integral champion for SL1 success. I wanted to share with you these wonderful advocates, our finalists, in the hopes it inspires you to share your stories of success with our new Nexus community! Stay tuned for our upcoming 2024 Innovators Awards, an application-based awards program celebrating and recognizing customers and partners who are leading the charge in digital transformation, operational excellence, innovation, and business impact utilizing SL1 in innovative ways. Applications are opening early June! Read more in our CS Honoree eBook. Congratulations to each of our 2024 Honorees! 👏💣 If you're interested in telling your SL1 story, please reach out to me, and join our Pathfinders customer advocate program.43Views2likes0CommentsServiceNow SyncPack Certification Update - Xanadu
Hello all – We are pleased to announce that ScienceLogic's latest integrations with ServiceNow are certified with ServiceNow Xanadu! This is an important milestone, taking place immediately after ServiceNow Xanadu was released. This is exciting news, because Each new ServiceNow release includes valuable features and enhancements that can significantly improve efficiency and functionality. Staying certified ensures our partners can leverage these innovations for their clients. As ServiceNow partners, being certified for the latest release is also crucial, because ServiceNow only maintains the last two releases (n-2). Older releases (more than two versions back) may no longer receive support or updates, making it challenging to troubleshoot issues or implement new features for clients still using outdated versions. As our customers update to the latest with ServiceNow's new releases, we ensure our scoped apps are certified every release to not only be in lock-step but also to leverage new capabilities. With Xanadu, ServiceNow has delivered their “Biggest AI Release Yet!” To learn more, see https://www.servicenow.com/community/releases-and-upgrades/ct-p/releases-and-upgrades. Thank you, Release Management39Views1like0CommentsScienceLogic - 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. ”33Views1like0CommentsPowerFlow output to Syslog repository
We're looking at enabling Syslog output to a central repository from PowerFlow at an application level. We've already got this running fine at an OS level and SL1 at an application level. Has anybody setup logging for PowerFlow? We're specifically interested in any login type data and also code changes. I've been through as much doc as I can find on the topic, such as: https://docs.sciencelogic.com/pdf/sciencelogic_powerflow_2-1-1.pdf https://docs.docker.com/engine/logging/drivers/syslog/ https://support.sciencelogic.com/s/article/10819 It doesn't appear straight forward to link log files in /var/log/iservices to their respective Docker services. I'm just looking for validation as much as anything, that Docker level logging of the contentapi and gui processes would be the way forward to capture all relevant security related information, and that all other processes can be ignored.30Views1like0CommentsConnect 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!25Views1like0CommentsServiceNow CMDB SyncPack v3.6.1
Hello, We are pleased to announce the release of ServiceNow CMDB SyncPack version 3.6.1. Dependency Note: To use this SyncPack, you must also install "ServiceNow Base" SyncPack version 3.8.1 or later with this release. Enhancements and Issues Addressed in This Release The following issues were addressed in this release: Added "cmdb_ci_wap_network" to the customer_ci_relations_overrides configuration option on the "Sync Devices from SL1 to ServiceNow" application. Addressed an issue that caused Device sync mappings to pull directly from the configuration object in PowerFlow. (Case ID: 00447321) Addressed an issue with the "Sync Interfaces from SL1 to ServiceNow" application that caused constant updates if the interface type was included in the mappings. As part of this fix, "type_id" was added to the default mappings, which will not be sent to the "cmdb_ci_network_adapter" or "cmdb_ci_lb_vlan" tables since the field does not exist on those tables in ServiceNow. (Case: 00464089) Made a series of updates to the "Sync Interfaces from SL1 to ServiceNow" application: Made an update to ensure that the interface "object_source_id" matches the CI table destination. For example, an interface which is sent to the "dscy_switchport" table will always have a native key containing "IFSWPort". The enable_advanced_topology toggle is now false by default, which means interface to interface relations are not sent by default. Added a new JSON mapping parameter, interface_advanced_mappings, which allows you to define the mappings for the combination of interface IANA type and parent device type to a specific ServiceNow table. This configuration option is blank by default, and must be configured to define the mappings you want to use. For more information about using this parameter, see the Configuring Additional Syncs for the ServiceNow CMDB SyncPack chapter in the ServiceNow CMDB SyncPack manual. Added a new JSON mapping parameter, interface_relation_mappings, which operates similarly to the relationship overrides in the Device Sync. This parameter allows you to define which interface relationships to send to ServiceNow. This configuration option is blank by default, and must be configured to define the relationships you want to send directly. (Case ID: 00446274) NOTE: If your ServiceNow instance is domain-separated, install the latest "ScienceLogic Domain Separation (Global)" update set in ServiceNow. Ask your ScienceLogic contact for access to this update set. Thank you, Release Management23Views0likes0CommentsPowerflow 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 Andre21Views0likes0CommentsServiceNow CMDB v3.6.2 SyncPack
Hello, We are pleased to announce the release of the ServiceNow CMDB v3.6.2 SyncPack. The following enhancements and issues were addressed in this release: Addressed an issue that caused incorrect relationships to be sent to ServiceNow when only child devices were sent for updates. (Case: 00492036) Addressed an issue with the "Sync Devices with SQL" application that caused the device collection mode/state to always show as "active" when synced to ServiceNow, regardless of the actual device state. (Case: 00489043) Addressed an issue where CI classes in ServiceNow with a 'region' field caused issues with disconnects being sent from PowerFlow. The 'region' field from ServiceNow on a CI is now saved on the Python object as "snow_ci_region". (Case: 00493761) Updated the SyncPack to correctly handle an SL1 platform change starting in version 12.1.0 for creating custom links through GraphQL. This release is made to work with SL1 version 12.1 or later SL1 PowerFlow version 2.6.0 or later Base Steps SyncPack version 1.5.5 or later ServiceNow Base SyncPack version 3.8.2 or later ServiceNow version Tokyo or later, with Web Services enabled ScienceLogic SL1: CMDB & Incident Automation certified application version 1.0.81 With the release of this SyncPack, older versions of the ServiceNow CMDB SyncPack have been suspended. Thank you, Release Management20Views0likes0Comments