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?SL1 PowerFlow v3.2.0 & PFCTL v2.8.0 Release
Hello, We are pleased to announce the release of SL1 PowerFlow v3.2.0, as well as the release of SL1 PowerFlow powerflowcontrol (pfctl) command-line utility v2.8.0. Both of these releases are included on the customer portal for download under Product Downloads > PowerFlow Platform > SL1 - PowerFlow 3.2.0. SL1 PowerFlow v3.2.0 adds the ability to bulk download reports, adds a new API endpoint to support bulk downloading of reports, adds two new configuration options to the docker-compose.yml file, and addresses multiple issues. Read on for more details or see the SL1 PowerFlow Release Notes. SL1 PowerFlow powerflowcontrol (pfctl) command-line utility v2.8.0 updates Couchbase-related checks, updates pfctl checks to require HTTPS certificates, and updates the pfctl init-sps action to use the HOST_ ADDRESS for the PowerFlow system. See the SL1 PowerFlow powerflowcontrol (pfctl) command-line utility v2.8.0 Release Notes. Features (SL1 PowerFlow v3.2.0) This section covers the features that are included in SL1 PowerFlow Platform version 3.2.0: You can now bulk download reports in PowerFlow. When bulk downloading, you have the option to select multiple specific instances of a report to download, or you can select all available instances to download. Added the new DELETE/api/v1/reports/batch API endpoint, which allows you to delete reports in a batch. For more details about using the new endpoint, see the API documentation in the PowerFlow user interface. Added two new configuration options to the docker-compose.yml file to allow access to the Couchbase and RabbitMQ user interfaces without requiring Dex authentication: DISABLE_DEX_AUTH. This option allows you to disable Dex authentication for the Couchbase and RabbitMQ services. ENABLE_SECONDARY_CB_UI. This option allows you to access the Couchbase user interface on port 8091 through secondary nodes without additional port openings. NOTE: The DISABLE_DEX_AUTH and ENABLE_SECONDARY_CB_UI configuration options are intended only for troubleshooting and should be turned off when the PowerFlow system is stable. Blank spaces in configuration options or application variables are now automatically stripped by the PowerFlow API to prevent the spaces from causing issues when PowerFlow reads the values. Updated API service initialization messages to improve clarity when Couchbase indexes are created. Updated the db_host configuration option to function more uniformly across all PowerFlow services. The following images are included in this release of PowerFlow: registry.scilo.tools/sciencelogic/pf-api:rhel3.2.0 registry.scilo.tools/sciencelogic/pf-couchbase:6.6.0-14 registry.scilo.tools/sciencelogic/pf-dex:2.37.1-11 registry.scilo.tools/sciencelogic/pf-worker:rhel3.2.0 registry.scilo.tools/sciencelogic/pf-gui:3.2.0 registry.scilo.tools/sciencelogic/pf-pypi:6.3.1-15 registry.scilo.tools/sciencelogic/pf-rabbit:3.8.35-7 registry.scilo.tools/sciencelogic/pf-redis:6.2.14-6 Issues Addressed (SL1 PowerFlow v3.2.0) The following issues were addressed in this release: Addressed an issue that caused device sync to fail due to region-specific cache key issues. (Case: 00422286) Addressed an issue that caused intermittent authentication failure when using SSO credentials to access PowerFlow. (Case: 00352925) Addressed an issue that caused the pfctl utility to fail when changing the PowerFlow password if the "dollar-sign" character ($) was used in the new password. You can now use the $ character in the PowerFlow password. (Case:00484230) Updated custom mappings values so that you can set any value you want before PowerFlow checks whether the value is unique. Previously, if you attempted to add a custom value and any part of the string matched an existing custom value, you could not attempt to save the value. Addressed an issue that prevented users with view-only permissions from accepting the End User License Agreement (EULA). Additionally, we have released SL1 PowerFlow System Utils v1.2.1 SyncPack today. This release is available on the customer portal here. This SyncPack requires the Base Steps SyncPack. Thank you, Release ManagementBase Steps SyncPack v1.6.0 Release
Hello, We are pleased to announce the release of Base Steps SyncPack v1.6.0. This release deprecates the QueryGQL step from the SyncPack (although it is not removed) and adds the GQLRequest step, which you should use to make GraphQL steps going forward. This release addresses two more issues: Addressed an issue that caused the "Sync Service Requests from ServiceNow to SL1" application to fail after upgrading SL1 from version 12.1.2 to 12.3.5. (Case: 00532575) Addressed an issue that caused the "DeleteFromCache" step to fail when using the 'equals' lookup type instead of 'like'. This release is now available on the customer portal under Product Downloads > PowerPacks & SyncPacks here. Read the full release notes here: https://docs.sciencelogic.com/powerpack_release_notes/sciencelogic_base_steps_syncpack-v160_release_notes.pdf Thank you, Release ManagementServiceNow 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 ManagementServiceNow 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 ManagementScienceLogic's PowerFlow Training: Explore Built-In Integration and Custom Automation Capabilities
PowerFlow is ScienceLogic’s integration platform designed to seamlessly extract, transform, and load data between SL1 and third-party tools. Whether you're implementing built-in integrations or creating custom automations, PowerFlow empowers you to streamline workflows, integrate systems, and enhance IT operations. Find the Right Training for Your Needs Explore training options based on your role and objectives: PowerFlow: ScienceLogic's Bi-Directional Task Execution Platform (1 hour) Discover PowerFlow’s core functionality in this introductory learning path, covering key features, configuration, navigation, and troubleshooting. PowerFlow Integrations: ServiceNow (4 hours) Master PowerFlow’s integration with ServiceNow. This comprehensive learning path includes all content from the introductory PowerFlow course, then dives deeper into implementing SL1 and ServiceNow integration use cases. PowerFlow: Software Development Kit (SDK) (1 hour) For advanced users, this training course shows how to use the PowerFlow Software Development Kit (SDK) to build custom SyncPacks for automation, system integration, and workflow enhancements. Access Training Anytime, Anywhere ScienceLogic University is ScienceLogic's on-demand learning portal. Log in or create an account here to access these PowerFlow training options and other essential topics.Optimising PowerFlow Integrations: Isolating Incident and CMDB Workloads
In complex IT environments, integrations like incident management and Configuration Management Database (CMDB) synchronisation are pivotal. ScienceLogic's PowerFlow platform offers robust capabilities to handle these integrations. However, to ensure optimal performance and prevent resource contention, it's crucial to configure dedicated steprunners and queues for different workloads. This article discusses on-premises instances of PowerFlow. If you are using a SaaS-hosted instance of PowerFlow, please submit a service request via the Support Portal outlining your requirements. The relevant team will then review your request and discuss the necessary changes to be made on your SaaS instance of PowerFlow. Understanding the Challenge Incident management and CMDB synchronisation have distinct characteristics: Incident Management: Typically involves lightweight, high-frequency tasks that require rapid processing to maintain real-time responsiveness. CMDB Synchronisation: Often deals with bulk data operations, such as syncing large volumes of configuration items, which are resource-intensive and time-consuming. Running both integrations on the same steprunner can lead to performance issues. For instance, a heavy CMDB sync might consume significant resources, delaying the processing of critical incident tasks. Implementing Dedicated Steprunners and Queues To address this, PowerFlow allows the configuration of steprunners to listen to specific queues. By assigning separate queues for incident and CMDB tasks, you can isolate their processing and allocate resources appropriately. Example Configuration Here's how you might define dedicated steprunners in your docker-compose.override.yml: Incident Steprunner: steprunner-incident: image: sciencelogic/is-worker:latest hostname: "incident-{{.Task.ID}}" deploy: resources: limits: memory: 2G replicas: 10 environment: user_queues: 'incident_queue' worker_threads: 4 CMDB Steprunner: steprunner-cmdb: image: sciencelogic/is-worker:latest hostname: "cmdb-{{.Task.ID}}" deploy: resources: limits: memory: 4G replicas: 5 environment: user_queues: 'cmdb_queue' worker_threads: 2 In this setup: user_queues: Assigns each steprunner to a specific queue (incident_queue or cmdb_queue), ensuring isolation of workloads. worker_threads: Defines how many concurrent tasks each steprunner container can process. Higher for incidents because incident syncs are typically lightweight and frequent. Lower for CMDB to reduce memory contention since CMDB data is often bulkier and more complex. deploy.resources.limits.memory: Caps how much memory each steprunner container can use. This helps prevent individual steprunners from consuming excessive memory, which is especially important when running many containers on shared infrastructure. Example: 2G for incidents (moderate), 4G for CMDB (higher due to heavier payloads). deploy.replicas: Specifies how many containers to run for each steprunner service. More replicas for incidents to handle high throughput. Fewer for CMDB, since each task may take longer and use more resources. Benefits of Isolation Performance Optimisation: Ensures that resource-heavy CMDB tasks don't impede the processing of time-sensitive incident tasks. Scalability: Allows independent scaling of steprunners based on the workload demands of each integration. Resource Management: Facilitates fine-tuned allocation of system resources, reducing the risk of bottlenecks and failures. Monitoring and Adjustments Regular monitoring is essential to maintain optimal performance: Queue Lengths: Persistent growth in queue lengths may indicate the need for additional steprunners or increased thread counts. Resource Utilisation: Monitor CPU and memory usage to prevent over utilisation. Error Rates: High error rates might necessitate adjustments in configurations or error-handling mechanisms. Final Thoughts By strategically configuring dedicated steprunners and queues for incident and CMDB integrations, you can enhance the efficiency, reliability, and scalability of your PowerFlow environment. This approach ensures that each integration operates within its optimal parameters, delivering better performance and resource utilisation.
