Vydělávej až 160.000 Kč měsíčně! Akreditované rekvalifikační kurzy s garancí práce od 0 Kč. Více informací.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Lekce 9 - Aplikační katalog a Konfigurační databáze CMDB v ObjectGears

V minulé lekci, Objekty systému ObjectGears - Vlastnosti objektu Sloupce, jsme si popsali detailnější vlastnosti sloupců pro třídu.

V dnešním ObjectGears tutoriálu si něco řekneme o Konfigurační databázi (CMDB), která je řešením primárně používaným IT organizací. Protože se kolem tohoto centrálního repository dat o IT točí všechny možné IT procesy, budou se s těmito daty setkávat i uživatelé mimo IT.

Standardní obrazovky Configuration management ObjectGears lze velmi efektivně používat v rámci IT. Uživatelům mimo IT je vhodné zobrazit příslušná data z Konfigurační databáze CMDB formou zvláštních stránek, které jim nabídnou všechny potřebné scénáře.

Vytvoříme si tak stránku, která bude skvělou vizitkou IT, zvláště pokud uživatelům nabídneme i cool scénáře, které se jim budou hodit.

Stránka se seznamem aplikací zobrazená formou Aplikačního katalogu může vypadat například takto:

Katalog aplikací: Vzhled - Systém ObjectGears

Každá aplikace je reprezentována řádkem s ikonou aplikace, názvem a krátkým popisem. Řádek můžeme rozkliknout a objeví se detailní informace o aplikaci, které chceme sdílet s uživateli mimo IT.

Detailními informacemi mohou být např. klíčové uživatele aplikace, jejího garanta, informace k licencování či Release notes.

Dále vidíme eventuální moduly, pokud se aplikace dále člení.

Moduly mohou být např: Systém SAP může být zastoupen záznamem pro platformu jako takovou a dále moduly FI, MM … atd, které mohou mít jiné garanty a klíčové uživatele).

Záznamy jednotlivých aplikací můžeme sdružit do skupin např.:

  • Grafické nástroje,
  • Podpůrné nástroje týmu Finance,
  • Vývojářské nástroje.

Katalog pak bude působit čistším a úhlednějším dojmem, než kdyby v něm byly spousty drobných aplikací, které většina uživatelů ani nezná.

Takto jsou tyto drobné aplikace (často jsou jich v organizacích i desítky až stovky) dostupné až po rozkliknutí položek z první úrovně.

Důležité je, že zde sdílíme existující data z Konfigurační databáze CMDB v nové aplikaci, v které uživatelům nabídneme zajímavé scénáře:

  • Nahlásit incident vztahující se k aplikaci.
  • Požádat o instalaci.
  • Přejít do detailu konfigurační položky.
  • Zobrazit komponenty aplikace – vidíme na jakých serverech aplikace běží. Můžeme prokliknout do detailu dané položky. Schéma si vytvoříme takové, jaké potřebujeme, odpovídající našemu datovému modelu a tomu, co chceme daty říci.
  • Zobrazit mapu procesů, které aplikace podporuje.
  • Zobrazit dokumentaci.

Vše je samozřejmě podmíněno přístupovými oprávněními, takže uživatelům se zobrazí pouze volby, které mohou použít.

Uživatele tak vtáhneme do procesů a zobrazíme jim informace, které často zůstávají skryty mimo okruh IT uživatelů. Přístup, kdy něco kontrolujeme kvůli tomu, že máme informace a jiné týmy ne, myslím, není tou správnou cestou vpřed. Běžný uživatel mimo IT, by neměl znát infrastrukturní detaily (to, na jakých serverech aplikace běží), ale může již vědět, v jakých procesech se aplikace používá, zvláště pokud je např. business vlastníkem či garantem dané aplikace.

Pokud tyto informace IT neposkytuje, aplikuje defenzivní přístup, který se podle mého názoru nemůže v dlouhém období osvědčit. IT management by neměl pouze hledat nižší náklady, vyšší bezpečnost nebo směřování k cílové architektuře, ale pokusit se překlenout mezeru mezi IT a business světem.

Konfigurační databáze, související procesy a konkrétně například sofistikovaný Aplikační katalog mohou být cestou, jak toho dosáhnout a získat oprávněný respekt za otevřenost, iniciativu a aktivní přístup.

Tvorba Aplikačního katalogu

Jak takový Aplikační katalog, čerpající data z Konfigurační databáze CMDB, vytvořit?

Tvorbu si popíšeme na příkladu Konfigurační databáze CMDB low-code development platformy ObjectGears.

Půjdeme na to ve třech krocích:

Krok 1 - Definujeme si požadavky na řešení

Tento krok spočívá ve vytvoření vize řešení, které jsme si popsali výše.

Vize řešení obsahuje i data, která chceme zobrazovat a funkcionality pro uživatele.

Krok 2 - Návrh řešení

Definujeme datový model. Zde nejspíše využijeme již existující konfigurační databázi, takže si spíše jen specifikujeme podkladové třídy, z nichž budeme zobrazovat data a jejich vazby:

Aplikační katalog: Datový model - Systém ObjectGears

Návrh struktury a fungování stránky zobrazující data

Určíme si jaké objekty připojíme k tlačítkům – většinou je již v aplikaci máme.

Zobrazení tlačítek bychom měli podmínit příslušnými rolemi, aby se tlačítka zobrazovala jen uživatelům, kteří danou akci skutečně mohou provést a dokončit.

Tlačítka mohou např:

  • Založit incident týkající se zobrazované aplikace - otevře nový záznam incidentu a předvyplní dotčenou aplikaci z Katalogu aplikací.
  • Požádat o instalaci aplikace - otevře nový záznam požadavku na instalaci a předvyplní dotčenou aplikaci z Katalogu aplikací.
  • Konfigurační položka - zobrazí konfigurační položku (detail dat zobrazených v Katalogu aplikací).
  • Produkční komponenty - zobrazí dané schéma aplikačních komponent, rozhraní a infrastruktury zajišťujících běh aplikace a předá mu dotčenou aplikaci, pro níž se má schéma zobrazit.
  • Schéma procesů - zobrazí schéma procesů podporovaných aplikací a předá mu dotčenou aplikaci, pro níž se má schéma zobrazit.
  • Zobrazit dokumentaci - zobrazí dokumentaci související s aplikací. Stránce se předá proměnná, která povede na zobrazení příslušného článku.

Krok 3 - Vytvoření řešení

Podívejme se, jak bude fungovat spolupráce jednotlivých komponent řešení:

Aplikační katalog: Komunikace objektů - Systém ObjectGears

Oranžové bloky jsou ObjectGears objekty, které v ObjectGears vytváříme jako záznamy s určitými vlastnostmi.

Popíšeme si jednotlivé očíslované kroky z obrázku:

1 - Vše začíná uživatelem používajícím Prohlížeč, který volá stránku Aplikačního katalogu.
2 - Server odpoví a vrací mu stránku obsahující Webpart Skript.
3 - Webpart Skript v prohlížeči asynchronně volá další objekt Spouštěný skript a ten volá jednu z funkcí v objektu Blok skriptu.
4 - Tato funkce načte data z Cache, a pokud zde žádná nejsou, načte je z databáze, uloží do Cache pro zrychlení příštích dotazů a vrátí tato data prohlížeči ve formátu json.
6 - Prohlížeč při prvním volání stránky stáhnul také soubor s Javascriptem Soubor.js, který generuje obsah stránky Aplikačního katalogu, a další soubor Soubor.css s kaskádovými styly, který obsah stránky formátuje – řeší tedy např. vzhled a barvu tlačítek, velikost písma, fonty a podobně.
7 - V souvislosti s použitím cache musíme počítat se situací, kdy jiný uživatel aktualizuje data ve třídě s aplikacemi. Na to musí reagovat pravidla po přidání, aktualizaci a mazání záznamů, které volají funkci bloku skriptu, která vyčistí cache.

Kaskádové styly formátují obsah stránky - řeší tedy např. vzhled a barvu tlačítek, velikost písma, fonty a podobně.

A jaký katalog aplikací používáte v organizaci vy? Líbí se vám přístup propojení seznamu aplikací s potřebnými scénáři? Napište nám prosím níže v komentářích.

V další lekci, Objekty systému ObjectGears - Role a řízení přístupu, si detailněji popíšeme objekt Role a způsob řízení přístupu uživatelů.


 

Předchozí článek
Objekty systému ObjectGears - Vlastnosti objektu Sloupce
Všechny články v sekci
Systém ObjectGears
Přeskočit článek
(nedoporučujeme)
Objekty systému ObjectGears - Role a řízení přístupu
Článek pro vás napsal Pavel Carvan
Avatar
Uživatelské hodnocení:
1 hlasů
Aktivity