Skillnader

Här visas skillnader mellan den valda versionen och den nuvarande versionen av sidan.

--- miner:integrationer:provisionering [2026/06/05 11:57] – [Provisionering till grafdatabas] dokuadmin
+++ miner:integrationer:provisionering [2026/06/05 12:03] (aktuell) – [Förvaltning] dokuadmin
@@ Rad 90: / Rad 90: @@
   * kommentarer och arbetsinformation
-Grafdatabasen kan användas för dokumentation och analys av integrationens struktur, men den kan även användas för att skapa nya datamodeller (exempelvis i enlighet med REC/Brick eller andra datamodeller) utifrån informationen från Miners grafdata.
+Grafdatabasen kan användas för dokumentation och analys av integrationens struktur, men den kan även användas för att skapa nya datamodeller (exempelvis i enlighet med REC/Brick eller andra datamodeller) utifrån informationen från Miners grafdata. En grafdatabas kan även användas som ett generellt datalager med data från andra datakällor, såsom från fastighetssystem, ärendehantering med mera.
-Läs mer om metadata och kunskapsmodell på sidan [[miner:integrationer:metadata#metadata_och_kunskapsmodell|Metadata och kunskapsmodell]].
+Ta [[https://iquest.se/kontakta-oss|kontakt med oss]], så berättar vi gärna mer och ger dig demonstrationer inom detta område.
 ===== Exempel: ProptechOS =====
@@ Rad 114: / Rad 113: @@
   * [[integration:proptech_os#starta_jobbet_foer_dataoeverfoering|Starta jobbet för dataöverföring]]
-===== data_access vid provisionering =====
-Attributet ''data_access'' kan påverka hur datapunkter skapas eller visas i mottagande system.
-^ Värde ^ Betydelse ^
-| ''r'' | Datapunkten kan läsas. |
-| ''rw'' | Datapunkten kan både läsas och skrivas. |
-I vissa mottagande system kan datapunkter med ''data_access=r'' hanteras som läsbara mätpunkter, medan datapunkter med ''data_access=rw'' kan hanteras som styrbara datapunkter eller aktuatorer.
-Det är därför viktigt att inte alla tekniskt skrivbara datapunkter automatiskt behandlas som styrbara i mottagande system.
-Läs mer på sidan [[miner:integrationer:metadata#data_access|Metadata: data_access]].
-===== Identifierare och dubbletter =====
-Provisionering kräver stabila identifierare.
-Om samma datapunkt provisioneras flera gånger behöver Miner och mottagande system kunna avgöra om objektet redan finns eller om ett nytt objekt ska skapas.
-Identifiering kan baseras på exempelvis:
-  * ''UUID''
-  * ''source_label''
-  * ''label''
-  * källsystem
-  * anslutning
-  * byggnad
-  * system
-  * komponent
-  * funktion eller kvalificerare
-  * extern identifierare i mottagande system
-En stabil identifieringsprincip minskar risken för dubbletter och gör det lättare att uppdatera befintliga objekt.
-Läs mer på sidan [[miner:integrationer:metadata#identifierare_och_nycklar|Metadata: Identifierare och nycklar]].
-===== Uppdatering av redan provisionerad information =====
-Provisionering kan användas både för att skapa ny information och för att uppdatera befintlig information.
-Exempel på uppdateringar:
-  * ändrat visningsnamn
-  * korrigerad systemtillhörighet
-  * ändrad enhet
-  * kompletterad klassificering
-  * korrigerad läs-/skrivbarhet
-  * tillagd relation
-  * borttagen eller avaktiverad datapunkt
-Vid uppdatering är det viktigt att förstå om mottagande system stödjer uppdatering av befintliga objekt eller om ändringar kräver manuell hantering.
-===== Avaktivering och borttag =====
-I vissa fall behöver datapunkter eller objekt tas bort eller avaktiveras i mottagande system.
-Det kan exempelvis bli aktuellt när:
-  * datapunkten inte längre används
-  * källsystemet har ändrats
-  * objektet har provisionerats felaktigt
-  * en integration har ersatts
-  * en datapunkt har bytt identifierare
-Borttag bör hanteras försiktigt, särskilt om mottagande system har historik eller relationer som är beroende av objektet.
-I många fall är det bättre att avaktivera ett objekt än att radera det helt.
-===== Kvalitetssäkring före provisionering =====
-Innan provisionering genomförs bör metadataunderlaget kvalitetssäkras.
-Kontrollera särskilt att:
-  * rätt datapunkter är valda
-  * nödvändiga grundattribut finns kvar
-  * ''config_status'' är korrekt
-  * ''data_access'' är korrekt
-  * obligatoriska metadatafält är ifyllda
-  * identifierare är stabila och unika
-  * visningsnamn är rimliga
-  * enheter och mätstorheter är korrekta
-  * relationer till byggnad, system, komponent eller placering är rimliga
-  * eventuella klassificeringar följer valt metadataupplägg
-  * avvikelser är dokumenterade
-Läs mer på sidan [[miner:admin:qa|QA]].
-===== Vanliga fel och kontroller =====
-^ Problem ^ Möjlig orsak ^ Kontroll ^
-| Objekt skapas dubbelt | Identifierare är inte stabila eller har ändrats. | Kontrollera ''UUID'', ''source_label'', ''label'' och eventuell extern ID-logik. |
-| Objekt saknas i mottagande system | Datapunkten är inte klarmarkerad eller saknar nödvändig metadata. | Kontrollera ''config_status'' och obligatoriska metadatafält. |
-| Fel typ av objekt skapas | Klassificering eller ''data_access'' är felaktig. | Kontrollera metadata, klassfält och läs-/skrivbarhet. |
-| Relationer saknas | Metadata för byggnad, system, komponent eller placering är ofullständig. | Kontrollera relationsfält och valda metadataattribut. |
-| Provisionering misslyckas | Felaktig anslutning, behörighet eller nätverksåtkomst. | Kontrollera API-nycklar, användarkonton, endpoint och loggar. |
-| Metadata visas fel | Fel fältnamn, prefix eller värdeformat. | Kontrollera attributnamn, prefix och mottagande systems krav. |
-===== Förvaltning =====
-Provisionering kan behöva köras igen när integrationen förändras.
-Exempel:
-  * nya datapunkter läggs till
-  * datapunkter tas bort eller avaktiveras
-  * metadata korrigeras
-  * systemstruktur ändras
-  * relationer uppdateras
-  * mottagande system får nya krav
-  * integrationen migreras eller byggs om
-Spara och förvalta metadataunderlaget så att ändringar kan spåras över tid.
 ===== Relaterade sidor =====