7/17/2019 6:45 PM

1/31/2025 12:57 PM

This article will explain the importance of SWIS service and its effects (such as poor web performance) if the said service fails.

Orion Platform

Benefits of SWIS

Why get data from SWIS instead of just querying the Orion database directly?

• Credentials
  • To access the Orion database directly, you need database credentials which a database administrator must create and manage using SQL tools.
  • By using SWIS to access the database, you effectively bypass the need for database credentials, using the same credentials you use to access the Orion website.
  • Thus, Orion administrators can manage SWIS access simply by using the Orion Web Console.
• Account Limitations
  • Orion administrators can associate Orion accounts with limitations that restrict what nodes and interfaces users can access.
  • SWIS respects these limitations when they provide information. For example, SWIS will only return nodes the user has permission to see when the user runs a query for nodes.
• Insulation from Database Schema Changes
  • SWIS ultimately satisfies most queries by fetching data from the database.
  • But the mapping between SWIS entities and the underlying database tables allows SolarWinds to evolve the database schema while providing a consistent, backward-compatible object model to SWIS clients.
• Higher-level Operation
  • By adding object-oriented features to the relational data model, SWIS allows for tools to operate at a higher level of abstraction.
  • Tools can query SWIS to find out what data is available and to tell which entities correspond to managed objects (like nodes, interfaces, and applications) and which entities contain statistical information.
  • SolarWinds uses this capability to build Network Atlas, which allows users to put any kind of managed object on a map, not just specific types.
• Manipulating Data Using the Invoke Interface
  • The SWIS query interface is read-only and cannot be used to insert, update, or delete data.
  • SWIS provides an Invoke interface for users to make changes to Orion.
  • Some entity types define verbs that can be called through this interface.
  • For example, Orion.AlertActive defines an Acknowledge verb that users can use to mark alerts as acknowledged.
  • Because this goes through SWIS, the Acknowledge verb can securely validate that the current user has permission to acknowledge alerts and can record the name of the user doing the acknowledging and the corresponding timestamp.
• Manipulating Entities Using the CRUD Interface
  • SWIS supports an interface for creating, reading, updating, and deleting entities.
  • These create, read, update, and delete (CRUD) operations comprise a generic interface through which you can access any entity type exposed by SWIS and manipulate the entity in a uniform fashion.
  • However, there may be entity types that do not support this interface or provide only limited support due to technical or design reasons. In these cases, the operations may reject requests.
• SWIS URI
  • CRUD operations use URIs to address entities.
  • The format of the URIs is outlined in the diagram below and allows you to select entities.
  • SWIS does not define a URI for entity types without at least one key property defined, so you cannot use these entities with CRUD operations.
  • You can view the key properties for an entity type in the tree pane of SWQL Studio.

Log location

Log File	Service	Location
Orion.InformationService.log	SolarWinds Information Service v2	C:\ProgramData\Solarwinds\InformationService\v2.0
Orion.InformationService.log	SolarWinds Information Service v3	C:\ProgramData\Solarwinds\InformationService\v3.0

SWIS - Subscriptions

It works like this:

1. Listener (e.g. auditing) creates subscription that is interested in some changes
2. Publisher (typically BL or Collector) publishes the messages, which is somebody interested in and sends it to SWIS pubsub (Publish&Subscribe)
3. SWIS tries to deliver it. 
   If the endpoint is unreachable (e.g. connection to Additional Web Server), stores the notifications to PendingNotifications. 
   Otherwise holds the message in memory (SWIS Service) and tries to deliver.

Also, there is a retry interval, when the Pending notifications attempt to resend.

SWIS - PendingNotifications

The PendingNotifications are created by the existing set of subscriptions found in the subscriptions table.
Pending Notifications table store the temporarily undeliverable notifications from pubsub. 
If the Notifications consumer (e.g. the auditing, NCM) is slow, then it could stuck in memory. You could try to restart BL to see if this resolves it.
The problem is usually, when some new subscription is related (e.g. auditing) and the old one still exists...... then you get the FK error.
If the notifications are the cause, I'd choose following procedure:
1. Stop SWIS and BL
2. delete from subscriptions (to get rid of old subscribers)
3. Start the services again. This should reinitialize the subscriptions

Publish and Subscribe

Goals

There are several goals for this architecture. It should provide:

• A replacement for the ad-hoc change tracking that is done in various places for things like recreating job engine job descriptions when node polling interval changes.
• A foundation for implementing the features of the basic alert system without the standard poller.
• Extensibility to data sources beyond the Orion SQL database.
• A basis for synchronizing nodes between Orion and other databases like NCM, Profiler, and third-party systems.

Terminology

There are three primary roles in this system:

• Change publisher – a poller, collector, business layer or other service that acts as a source of change data. Changes can originate from data collection or user action.
• Change subscriber – any component interested in specific change data. This could be an alerting service that will trigger or reset alerts in response to particular conditions, a business layer that will recreate jobs when necessary, or a service that synchronizes with another data source (if this is bidirectional synchronization, this service might also be a change publisher).
• Change broker – a new component that acts as an intermediary between change publishers and change subscribers. It is responsible for determining which published change data is interesting to which subscribers and delivering it.

Logs Located in:    

Orion Server: C:\ProgramData\Solarwinds\InformationService\v3.0   
Diagnostics: SolarwindsDiagnostics.zip\LogFiles\Orion

This log file is also referred to as SWISv3 logs
 
1.  Shows connections to SQL, from the Data Processor, and to/from the Module Engine (Business Layer Host)
2. Remember that the Information Service READS but does not WRITE to SQL
3. Correlate problems found in OrionWeb.log with these logs (errors, long running queries etc.)
4. Example error in OrionInformationService.log
ERROR SolarWinds.InformationService.ChangeBroker.NotificationManager - Unhandled exception occured delivering notification. SubscriptionId: a09ad1fb-0f4e-4969-972d-4b125cd928c7, Endpoint: net.tcp://localhost:17777/orion/vim/businesslayer/operationsubscriber, IndicationType: System.InstanceDeletedSystem.Data.SqlClient.SqlException (0x80131904): The INSERT statement conflicted with the FOREIGN KEY constraint "FK_SubscriptionPendingNotification". The conflict occurred in database SolarWindsOrion", table "dbo.Subscriptions", column 'Id'. The statement has been terminated. 

Issues

• Network Atlas is unable to connect to the SolarWinds Information Service (SWIS)