Översikt över anpassning av Service Manager informationslagret

Viktigt

Den här versionen av Service Manager har nått slutet av supporten, vi rekommenderar att du uppgraderar till Service Manager 2022.

När Service Manager informationslagret har distribuerats och du har visat dess rapporter kan du anpassa informationen i rapporterna så att den passar din organisation bättre. Du kan till exempel vilja återskapa rapporter som du tidigare använt med andra informationssystem med hjälp av Service Manager. Eller också vill du anpassa rapporterna för interna affärsprocesser för incidenter eller ändringshantering.

Med informationen i det här avsnittet får du hjälp med att utöka och anpassa datalagret för att möjliggöra djupanalyser.

Dimensionsmodellering för informationslager med hjälp av ett star-schema

Informationslagret i Service Manager är en uppsättning databaser och processer. Med de här processerna läggs information till i databaserna automatiskt. I korthet är syftet med informationslagret att lägga till information i dataarkivet där du och andra användare kör rapporter och utför analyser för att hantera din verksamhet. Service Manager lagrar informationslagerdata längre i lagret än i den Service Manager databasen på grund av att data är användbara för trender och analyser. Dessutom är data i datalagret ofta användbara under begränsad tid för gäller normal transaktionsbearbetning.

Datalagret är optimerat för aggregering och analys av stora mängder data på en gång på många till synes oförutsägbara sätt. Det här beteendet är annorlunda än i transaktionsinriktade bearbetningssystem, som optimerats för att ge skrivåtkomst till ett mindre antal poster i ett antal givna transaktioner, vilket gör att de här transaktionerna är mer förutsägbara.

För att optimera informationslagret för prestanda och användarvänlighet använder Service Manager Kimball-metoden för dimensionsmodellering. (Mer information om Kimball-metoden finns i Dimensionsmodellering.) Det innebär att tabeller i DWDataMart-databasen grupperas logiskt i ämnesområden som liknar en stjärna när de visas i ett diagram. Därför kallas de här grupperna ofta stjärnscheman, och de innehåller följande:

  • Mitt i stjärnan finns en faktatabell. Faktatabeller representerar relationer, mätvärden och KPI:n. Faktatabeller är normalt sett långa med relativt få kolumner, men de innehåller stora mängder transaktioner.
  • Faktatabellen kopplas till dimensionstabeller som innehåller klasser, egenskaper och uppräkningar. Dimensionstabeller innehåller vanligen mycket färre rader än faktatabellerna, men de har större bredd eftersom de innehåller attribut som rapportanvändarna använder när de skapar rapporter på olika detaljnivåer. Attributen kan vara status, klassificeringar och datum (till exempel Skapad datum eller Lösningsdatum) för en klass.
  • En utriggare är en speciell typ av dimensionstabell som är ett tillägg till en annan dimensionstabell av prestanda- och användbarhetsskäl.

När du föreställer dig stjärnschemat kan du till exempel tänka på hur det skulle se ut för ett café. Om transaktionerna motsvarar inköp av kaffe kan dimensionerna vara följande:

  • En datumdimension som konsoliderar transaktionen efter den vanliga kalendern respektive redovisningskalendern
  • En kunddimension som anger vem som gjorde inköpet
  • En personaldimension som anger vem som lagade till kaffet
  • En produktdimension som anger typen av kaffe, till exempel espresso, latte eller vanligt kaffe
  • En butiksdimension

Om vi tittar på vilka mätningar som faktatabellen kan innehålla kan det till exempel vara följande:

  • Såld kvantitet
  • Pris per enhet
  • Total försäljning
  • Total rabatt

IT-relaterade processer skiljer sig egentligen inte särskilt mycket från caféexemplet när det gäller den dimensionella modellen. Det finns några transaktioner som äger rum, till exempel incidentskapande, lösning och avslutning, som kan producera intressanta och användbara mätvärden, till exempel tid till lösning, måluppfyllelse för lösningen, faktureringsbar tid för analytiker och statusens varaktighet.

När du funderar på att utöka och anpassa datalagret är det viktigt att tänka igenom vilka verksamhetsrelaterade frågor du vill ha svar på, och undersöka vilken dimensionell modellering du ska använda för att få användbar information och bästa praxis. Mer information om hur du anpassar datalagret finns i övriga ämnen i det här avsnittet.

Faktatabeller i informationslagret

I det här avsnittet beskrivs hur du definierar relationsfakta i informationslagret i Service Manager. Ett relationsfakta i Service Manager informationslagret liknar en relation i Service Manager. Du kan använda dig av ett relationsfaktum för att besvara frågor, till exempel följande:

  • Vilka arbetsobjekt som för närvarande är tilldelade användaren Magnus Hedlund, så att du kan ta reda på vilken status de har.
  • Vad är listan över alla datorer i domänen som för närvarande har Windows 10 installerade så att du kan uppdatera dem till den senaste versionen?
  • Vilka granskningsaktiviteter som har Katarina Larsson som granskare, så att de kan tilldelas någon annan eftersom hon är på semester.

I alla de här fallen finns en källinstans och en målinstans som är sammankopplade med en relation. Utan ett relationsfaktum är det svårt att identifiera associationerna mellan instanserna. Ta till exempel relationen i Microsoft.Windows.ComputerHostsOperatingSystem i hanteringspaketet Microsoft.Windows.Library i följande exempel:

<RelationshipType ID="Microsoft.Windows.ComputerHostsOperatingSystem" Accessibility="Public" Base="System!System.Hosting">
<Source ID="Computer" Type="Microsoft.Windows.Computer" />
<Target ID="OperatingSystem" Type="Microsoft.Windows.OperatingSystem" MaxCardinality="1" />
</RelationshipType>

I en Service Manager relation modelleras källan och målet alltid av en hanteringspaketklass. I den här relationen utgörs källan av klassen Microsoft.Windows.Computer och målet av klassen Microsoft.Windows.OperatingSystem. Följande information definierar motsvarande RelationshipFact baserat på Microsoft.Windows.ComputerHostsOperatingSystem-relationen:

<RelationshipFact ID="ComputerHostsOperatingSystemFact" Accessibility="Public" Domain="Domain.ConfigurationManagement" TimeGrain="Daily" SourceType="Windows!Microsoft.Windows.Computer" SourceDimension="ComputerDim">
<Relationships RelationshipType="Windows!Microsoft.Windows.ComputerHostsOperatingSystem" TargetDimension="OperatingSystemDim" />
</RelationshipFact>

Notera att relationsfaktumet definierar en källdimension och en måldimension. Du kanske märker att käll- och måldimensionerna är inriktade på käll- och målklasserna från den ursprungliga relationen som relationsfaktumet modelleras efter.

Du kan använda relationsfakta genom att associera två dimensioner, vilket gör att associationen kan användas av rapporter för att visa viktig information från båda dimensionerna i förhållande till den andra. Exempelvis kan du använda WorkItemAssignedToUser-relationen om du vill visa information om incidenter eller ändra begäranden för en viss användare i rapporten. På så sätt kan du navigera i data för att hitta just den information du behöver. Detta är bara ett exempel på hur relationsfakta kan användas för att skapa specialanpassade vyer över data i rapporter.

De attribut och underelementstaggar som krävs i modellen för ett relationsfaktum i ett användardefinierat hanteringspaket beskrivs i tabellen nedan för taggen <RelationshipFact>.

Attribut Description
ID En unik identifierare för relationsfaktaelementet. Detta är också tabellnamnet för relationsfaktumet i datalagret och dataarkivet.
Tillgänglighet Det här elementet ska alltid anges som Public eftersom distributionsprocessen skapar systemhärledda hanteringspaket som refererar till den här utriggaren när automatiska omvandlingar genereras.
Domain Relationsfaktumets omfattning. Möjliga värden är följande: Aktivitetshantering för instanshantering, ändringshantering för incidenthantering och problemhantering.

Värdet för det här attributet måste vara en uppräkning som är underordnad den överordnade Domain-uppräkningen, som definieras i hanteringspaketet Microsoft.SystemCenter.Datawarehouse.Base.
TimeGrain Relationsfaktumets detaljeringsnivå. Värdet måste vara något av följande: Varje timme, Varje dag, Varje vecka eller Varje månad.
SourceType Hanteringspaketklass för relationens källa.
SourceDimension Den dimension som har källklassen som mål. Detta är ett valfritt fält. Om ingen SourceDimension har angetts hittar Service Manager automatiskt den dimension som direkt riktar sig till själva källklassen eller den närmaste överordnade klassen för källklassen i klasshierarkin.

I ett faktum med flera relationer förblir källdimensionen alltid densamma. Däremot kan måldimensionen ändras, beroende på den specifika relationen. Varje relationstypsattribut i en faktum med flera relationer måste vara unikt. Nedan ges ett exempel på relationsfaktumet i hanteringspaketet WorkItemAssignedToAndCreatedByUser:

<RelationshipFact ID="WorkItemAssignedToAndCreatedUserFact" Accessibility="Public" Domain="Domain.InstanceManagement" TimeGrain="Daily" SourceType="WorkItem!System.WorkItem" SourceDimension="WorkItemDim">
<Relationships RelationshipType="WorkItem!System.WorkItemAssignedToUser" TargetDimension="UserDim" />
<Relationships RelationshipType="WorkItem!System.WorkItemCreatedByUser" TargetDimension="UserDim" />
</RelationshipFact>

I det här exemplet kan du se att även om måldimensionen är identisk för båda relationerna, så är själva relationerna unika. Det gör att relationsfaktumet är giltigt. Om du vill ha fler exempel på utriggare, dimensioner och relationsfakta kan du undersöka något av de datalagerhanteringspaket som ingår i Service Manager. Ett bra exempel är basdatalagerhanteringspaketet Microsoft.SystemCenter.Datawarehouse.Base.

Utriggare i informationslagret

En utriggare i informationslagret i Service Manager är i princip en lista som logiskt kan gruppera en uppsättning värden. I följande tabeller visas två exempel på logisk gruppering av värden som anger prioritet och Windows-operativsystem.

Prioritet
Låg
Medel
Högt
Windows-operativsystem
Windows 7
Windows 8
Windows 10

En utriggare är användbar på två sätt:

  • Du kan använda diskreta värden från en utriggare som en nedrullningsbara meny för en rapportparameter när du skapar och visar rapporter i Service Manager-konsolen.
  • Du kan använda utriggarvärden för att gruppera data i rapporter för avancerad analys.

Utriggare i datalagret kan ha en eller flera klassegenskaper som mål och sammanställa dem i en enda uppsättning diskreta värden. De här egenskaperna kan bara ha datatypen String eller ManagementPackEnumeration. När de baseras på en uppräkning bevarar utriggare även hierarkin. Service Manager stöder inte en utriggare som har definierats för en annan datatyp än String eller ManagementPackEnumeration.

Fördelen med att definiera en utriggare för en uppräkning är uppenbar, men det finns också en fördel med att definiera en utriggare för en strängkolumn och det är att datalagrets infrastruktur kombinerar de distinkta värdena för en egenskap från instansutrymmet till en kort lista. Du kan sedan använda den här listan som en enkel nedrullningsbar listruta i en rapport. Ett bra exempel på en strängbaserad utriggare är Manufacturer egenskapen i klassen Computer, som modelleras som en sträng i Service Manager-databasen. Genom att definiera en utriggare för den egenskapen kan du i Service Manager välja ett värde i den nedrullningsbara listrutan, i stället för att söka bland de tillverkare som du har skaffat datorerna från.

Om du vill visa ett exempel på hur en utriggare används i en rapport i parameterhuvudet öppnar du Service Manager-konsolen, navigerar till Rapportering, Aktivitetshantering och kör sedan rapporten Aktivitetsdistribution. Granska sedan listan Status för att se utriggarens värden. Du ser hur utriggaren har utformats i hanteringspaketet i följande exempel. Observera klassen System.WorkItem.Activity, som definieras i hanteringspaketet System.Workitem.Activity.Library:

<ClassType ID="System.WorkItem.Activity" Accessibility="Public" Base="WorkItem!System.WorkItem" Hosted="false" Abstract="true">
< Property ID="SequenceId" Type="int" />
<Property ID="Notes" Type="richtext" MaxLength="4000" />
<Property ID="Status" Type="enum" EnumType="ActivityStatusEnum" />
<Property ID="Priority" Type="enum" EnumType="ActivityPriorityEnum" />
<Property ID="Area" Type="enum" EnumType="ActivityAreaEnum" />
<Property ID="Stage" Type="enum" EnumType="ActivityStageEnum" />
</ClassType>

Därefter kanske du vill definiera en utriggare baserat på uppräkningsegenskapen Status. Följande exempel visar hur du kan definiera en utriggare i valfritt hanteringspaket:

<Outrigger ID="ActivityStatus" Accessibility="Public">
<Attribute ID="Status" PropertyPath="$Context/Property[Type='CoreActivity!System.WorkItem.Activity']/Status$" />
</Outrigger>

Som tidigare beskrivits kan du-hanteringspaketet author-define a outrigger on one or more class properties (Du kan definiera en utriggare för en eller flera klassegenskaper). Varje klassegenskap modelleras av ett motsvarande attribut i utriggaren. Följande är ett exempel på uppräkningsbaserad utriggarvisualisering. I det här exemplet är Aktivitetsstatus baserat på ActivityStatusEnum:

<EnumerationTypes>
<EnumerationValue ID="ActivityStatusEnum" Accessibility="Public" />
<EnumerationValue ID="ActivityStatusEnum.Ready" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="5.0" />
<EnumerationValue ID="ActivityStatusEnum.Active" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="10.0" />
<EnumerationValue ID="ActivityStatusEnum.OnHold" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="15.0" />
<EnumerationValue ID="ActivityStatusEnum.Completed" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="20.0" />
<EnumerationValue ID="ActivityStatusEnum.Failed" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="25.0" />
<EnumerationValue ID="ActivityStatusEnum.Cancelled" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="30.0" />
<EnumerationValue ID="ActivityStatusEnum.Rerun" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="35.0" />
...
</EnumerationTypes>

Vart och ett av värdena ingår i utriggarens uppsättning diskreta värden. Följande tabell visar kolumnerna ID och ActivityStatusValue från ActivityStatus-utriggaren, som innehåller alla uppräkningsvärden från ActivityStatusEnum.

ID ActivityStatusValue
ActivityStatusEnum.Completed Slutförd
ActivityStatusEnum Aktivitetsstatus
ActivityStatusEnum.Active Pågår
ActivityStatusEnum.OnHold Stoppad
ActivityStatusEnum.Rerun Kör igen
ActivityStatusEnum.Failed Misslyckad
ActivityStatusEnum.Ready Väntar
ActivityStatusEnum.Cancelled Avbrutet

I föregående tabell innehåller kolumnen ID från utriggaren alla EnumerationValue-ID:n från uppräkningstypen ActivityStatus. ActivityStatusValue är det faktiska, användarvänliga visningsnamnet som visas i rapportens nedrullningsbara menyer.

Följande exempel ger mer information om hur du konstruerar och modellerar en utriggare. Utriggaren ActivityStatus används åter som exempel:

<Outrigger ID="ActivityStatus" Accessibility="Public">
<Attribute ID="Status" PropertyPath="$Context/Property[Type='CoreActivity!System.WorkItem.Activity']/Status$" />
</Outrigger>

I följande tabell beskrivs attributen för taggen <Outrigger>.

Attribut Description
ID En unik identifierare för utriggarelementet. Detta är även tabellnamnet för utriggaren i datalagret och datamarten.
Tillgänglighet Det här elementet bör alltid vara inställt på Public.

Varje överordnad <Outrigger>-tagg innehåller en eller flera <Attribute>-undertaggar. I följande tabell beskrivs attributen för den här taggen.

Attribut Description
ID En unik identifierare för varje utriggarattribut.
PropertyPath PropertyPath-syntaxen, som måste identifiera den klass och det attribut som är mål för utriggarattributet.

Dimensioner i informationslagret

En dimension i Service Manager informationslagret i Service Manager är ungefär detsamma som en hanteringspaketklass. Varje hanteringsklass har en egenskapslista medan varje dimension har en attributlista. Varje dimensionsattribut motsvarar en egenskap i en klass.

Låt säga att en användare vill att en rapport i Service Manager ska visa viss information om attributen för datorerna i en viss domän. Användaren vill kanske ha reda på IP-adress, antalet logiska processorer och DNS-namn (Domain Name System) för varje dator. Med dimensioner kan användaren hämta informationen från Service Manager till datalagret där rapporter kan fråga efter och visa informationen för varje dator.

I Service Manager-datalagret har en dimension alltid en enda klass som mål. Dimensionsattributen mappas sedan till målklassens egenskaper. I det här exemplet har en datordimension klassen Microsoft.Windows.Computers som mål för att hämta information om en dators attribut.

I vissa fall som beskrivs närmare i det här avsnittet kan en dimension också mappas till egenskaperna för en målklasss basklass och härledda klasser. Även om en dimension kan vara ungefär jämförbar med en hanteringspaketklass, kan den därför även innehålla egenskaper som finns i hanteringspaketklassens hierarki.

Du kan se ett exempel på hur en dimension används i aktivitetsdistributionsrapporten. När du klickar på Lägg till under Välj berört konfigurationsobjekt (valfritt) i rapporten öppnas rutan Välj dimensionsobjekt och du kan söka efter dimensionsinstanser i dimensionen ConfigItemDim. Du kan filtrera på egenskapen Visningsnamn . När du väljer Alla Windows datorer som dimensionsobjekt uppdateras rapporthuvudet med det valda filtervärdet. När du kör rapporten visas endast aktiviteter som påverkar det valda konfigurationsobjektet Alla Windows datorer.

Om du vill se hur dimensionen har utformats kan du titta på klasserna System.Entity och System.ConfigItem som är definierade i hanteringspaketet System.Library:

<ClassType ID="System.Entity" Accessibility="Public" Hosted="false" Abstract="true" Singleton="false">
<Property ID="DisplayName" Type="string" MinLength="0" Key="false" CaseSensitive="false" MaxLength="4000" />
</ClassType>
<ClassType ID="System.ConfigItem" Base="System.Entity" Accessibility="Public" Hosted="false" Abstract="true">
<Property ID="ObjectStatus" Type="enum" EnumType="System.ConfigItem.ObjectStatusEnum" DefaultValue="System.ConfigItem.ObjectStatusEnum.Active" />
<Property ID="AssetStatus" Type="enum" EnumType="System.ConfigItem.AssetStatusEnum" />
<Property ID="Notes" Type="richtext" MaxLength="4000" />
</ClassType>

Om du vill ändra konfigurationsobjektdimensionen så att den har egenskaperna ObjectStatus och AssetStatus för System.ConfigItem och egenskapen DisplayName för basklassen System.Library som mål, kan du definiera dimensionen med följande egenskaper som attribut:

<Dimension ID="ConfigItemDim" Accessibility="Public" Target="System!System.ConfigItem" InferredDimension="true" HierarchySupport="Exact" Reconcile="true">
<InclusionAttribute ID="DisplayName" PropertyPath="$Context/Property[Type='System!System.Entity']/DisplayName$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="ObjectStatus" PropertyPath="$Context/Property[Type='System!System.ConfigItem']/ObjectStatus$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="AssetStatus" PropertyPath="$Context/Property[Type='System!System.ConfigItem']/AssetStatus$" SlowlyChangingAttribute="false" />
</Dimension>

I följande tabell visas information om hur du bygger upp och modellerar en dimension genom att undersöka elementen och attributen i XML-schemat för en <Dimension>.

Attribut Description
ID En unik identifierare för dimensionselementet. Detta är även tabellnamnet för dimensionen i datalagret och dataarkivet.
Tillgänglighet Det här elementet ska alltid vara inställt på "Public".
Mål Det hanteringspaketklassnamn som dimensionen har som mål.
InferredDimension Det här värdet är alltid True.
HierarchySupport Klasshierarki som gör det möjligt att definiera de egenskaper som ska ingå i dimensionen. Det finns tre möjliga värden:

1. Exakt
2. IncludeExtendedClassProperties
3. IncludeDerivedClassProperties

Mer information om dessa värden finns i följande avsnitt i den här artikeln.
Extends Valfri boolesk flagga som visar om dimensionen är en basdimension eller om den utökar en annan dimension. När en dimension har definierats kan du använda Service Manager informationslagret för att "utöka" dimensionen och lägga till fler attribut vid en senare tidpunkt.

Om flaggan Extends är inställd på True måste HierarchySupport vara inställt på Exact och alla tilläggsattribut måste finnas i listan. Standardvärdet för flaggan är False.
Reconcile Valfri boolesk flagga som visar huruvida två instanser som annars är identiska och bara skiljer sig åt vad gäller från vilken källa data hämtas, ska sammanställas till en enda datarad. Standardvärdet för flaggan är False.

För dimensioner avseende konfigurationsobjekt bör flaggvärdet vara True och för dimensioner avseende arbetsobjekt bör flaggvärdet vara False.

Attributet HierarchySupport fastställer vilka klasser som bearbetas och de särskilda attribut som ingår i dimensionen. Närmare information om varje möjligt värde beskrivs i följande avsnitt.

Exact

När attributet HierarchySupport är Exact måste du manuellt definiera alla attribut som ska ingå i dimensionen med hjälp av <InclusionAttribute>-taggen. Dessa attribut kan antingen vara från målklassen eller någon av målklassens basklasser och härledda klasser. Varje inkluderingsattribut motsvarar en klassegenskap. I följande tabell beskrivs alla attribut i <InclusionAttribute>-taggen.

Attribut Description
ID En unik identifierare för attributelementet.
PropertyPath PropertyPath-syntax som måste identifiera den klass och det attribut som är mål för dimensionsattributet.
SlowlyChangingAttribute Det här attributet bör alltid vara False.

I föregående ConfigItemDim-dimensionsexempel hade HierarchySupport värdet Exact. Därför bearbetas bara inkluderingsattributen (DisplayName, ObjectStatus, AssetStatus) i listan i transformeringen och ingår i dimensionstabellen i datalagrets databas och dataarkiv.

Värdet Exact för HierarchySupport kräver att du manuellt lägger till varje attribut i listan som du vill ha med i dimensionen. Det kan dock hända att du vill ha med alla attribut för en klass och även attributen från basklasserna och härledda klasser. I så fall kan det ta lång tid att lägga till varje attribut för sig i listan. I Service Manager finns därför två andra HierarchySupport-värden som automatiskt hanterar sådana här situationer åt dig. Dessa värden beskrivs i följande avsnitt.

IncludeExtendedClassProperties

För en dimension som har en HierarchySupport med värdet IncludeExtendedClassProperties ingår alla attribut för målklassen och alla dess basklasser i dimensionstabellen och transformeringen. Följande bild visar ett exempel: CarDimension, som riktar sig till klassen Bil och har HierarchySupport med IncludeExtendedClassProperties.

Diagram of IncludeExtendedClassProperties example

Eftersom CarDimension har klassen Car som mål och dess HierarchySupport-värde är IncludeExtendedClassProperties bearbetar den både klassen Car och dess basklass Vehicle. Tabellen och transformeringen innehåller attributen i följande tabell.

CarDimension-attribut
Färg
Modell
Modell
NumDoors
NumCupHolders
Horsepower
CargoSpace

IncludeDerivedClassProperties

För en dimension som har en HierarchySupport med värdet IncludeDerivedClassProperties ingår alla attribut för målklassen och alla basklasser och härledda klasser i dimensionstabellen och den tillhörande transformeringen.

I exemplet nedan har nu CarDimension en HierarchySupport med värdet IncludeDerivedClassProperties. Eftersom den bearbetar både basklasserna och de härledda klasserna för målklassen bearbetar dimensionen nu attributen för tre klasser: Fordon, Bil och Sportscar, enligt följande bild.

Diagram of IncludeDerivedClassProperties dimension

Dimensionstabellen och transformeringen för CarDimension innehåller attributen i följande tabell.

CarDimension-attribut
Färg
Modell
Modell
NumDoors
NumCupHolders
Horsepower
CargoSpace
TopSpeed