Uvolnění výroby – use case reálné Power Platform aplikace

Tento text berte jako malou případovku z tvorby Power Platform aplikace pro průmyslového výrobce v automotive. Třeba vás popsaný use case inspiruje při tvorbě podobného nebo ještě lepšího řešení u vás.

Jen malý disclaimer – popisuji to dost zjednodušeně a pokud něco 

Zadání

Co potřeboval zákazník?

Aplikaci pro uvolnění výroby. Uvolnění výroby je proces kontroly výrobních zařízení před spuštěním výroby nebo v jejím průběhu.

Zjednodušeně jde o to, že uživatel potřebuje v nějaký moment obejít relevantní linky / stroje, zapsat z nich hodnoty ukazatelů a potvrdit že je všechno v pořádku a výroba tedy může běžet v požadované kvalitě.

Vyplněné záznamy se pak uloží a archivují kvůli auditu a kvůli případnému dohledávání příčin problémů.

Jak appka rámcově funguje

• Člověk zodpovědný za kvalitu vyplňuje v Excelu, uloženém na SharePointu, informace o tom, pro který díl, kterou linku atd. se má co vyplňovat. V Excelu se data pomocí Power Query upraví do jednoduché tabulky použité návazně v appce.
• Z Excelu si data přebírá Power Apps pomocí Power Automate. Otázky se zobrazí v galerii operátorovi, který ve výrobní hale na tabletu zadá potřebné údaje. Pokud jsou všechny v normě, nebo pokud je vysvětlená případná odchylka, odešle informace do „archivu“ v SharePoint listu.
• Informace z Appky se ukládají do SharePoint listu pomocí Power Automate. V SharePoint listu jsou data uložená bez větších úprav, proto se sledují hlavně pomocí napojeného Power BI kde se z nich dají dělat libovolné pohledy.

Z  popisu by se mohlo zdát že jde o triviální appku naklikanou během obědové pauzy. Byznysová realita ale bývá vždy komplexnější a i tady se našlo dost komplikací jejichž ošetřování zabralo většinu práce na aplikaci.

Které výzvy jsme museli vyřešit a jak jsme na to šli?

Problém – licencování

S aplikací může časem pracovat relativně hodně uživatelů. Proto jsme se snažili vyhnout prémiovým licencím Apps i Automate, aby nebylo třeba je všem kupovat a aby stačily licence běžných 365.

To znamená nepoužívat Dataverse.

A nepoužívat Dataverse znamená používat zdroje jako Excel nebo SharePoint List.

Řešení – Excel jako datový zdroj

V jiném případě bychom si vybrali SharePoint List, ale tady se nám hodil Excel a jeho Power Query, které je super v tom jak umí z tabulky zadávané uživatelem vytvořit tabulku dobře čitelnou pro appku. Což v tomto případě byla velmi komplikovaná část projektu, protože prostě data byla složitá a obsahovala spoustu výjimek.

Problém je zřejmý – do Excelu (ani SharePoint listu) se appka nemůže napojit napřímo. Resp. může, ale při více než 2000 řádkách je problém s delegováním a to je dost zásadní. Takže?

Řešení – Power Automate načítající do kolekcí místo přímého připojení appky na zdroj

Z toho důvodu jsme zvolili řešení, kdy se data vezmou z Excelu pomocí Power Automate (akce List rows present in a table) a načtou se do kolekce. S kolekcí se pracuje a výsledek se zase uloží do databáze, tentokrát do SharePointu.

Kromě úspory za licence má práce s Power Automate a kolekcemi dvě výhody:

• Pohyb dat je přesně sledovatelný v logu Power Automate
• S daty v kolekci appka pracuje velmi rychle

Toto flow se volá poměrně často v průběhu běhu appky, ale zatím se zdá že jsme v rámci kapacit neprémiové varianty.

Opakované spouštění flow z různých prvků aplikace

S dotazováním appky do Excelu souvisí ještě jedna část řešení. Toto volání je na jednu stranu poměrně složité, na druhou stranu se v aplikaci volá z mnoha tlačítek a jiných prvků. Běžně by to znamenalo psát a udržovat jeden proces v mnoha kopiích.

Pro tuto konkrétní situaci se nehodilo použít custom funkci v Power Apps, takže jsem se uchýlil ke svém oblíbenému triku – na stránku se vloží skryté tlačítko, které např. sofistikovaně posílá data do flow. Ostatní prvky pak už volají jen něco jako

• Select(skrytetlacitko)

a tím flow volají. Jde to vlastně docela dobře parametrizovat tím, že se flow používá proměnné, které jsou z různých tlačítek plněny jinak. Není to čisté řešení, ale tady to funguje přesně jak má.

Výsledek

Výsledná aplikace nestojí uživatele na licencích nic navíc, protože vše je pokryté už existujícími licencemi 365 obsahujícími Power Apps i Power Automate, a aplikace dělá co dělat má.

Problém – komplexnost sledovaných otázek

Když operátor obchází výrobu a kontroluje, vyplňuje 5-15 údajů, přičemž aplikace rovnou ověřuje, jestli zadaná hodnota je nebo není OK. Příklad – pokud je povolená teplota 80°-90° stupňů, tak teplota 91° se rozezná jako problém.

Některé otázky jsou jen odškrtávací, jiné jsou typu „rozměr mezi 20 a 22 mm“, jiné mají horní nebo dolní hranici. Některé otázky se zapisují ručně, jiné čtečkou čarových kódů. Některé jsou definované textem, jiné obrázkem. Některé jsou povinné, jiné ne. Jiné otázky jsou pro proces kompletace výrobků, jiné pro proces vulkanizace. Některé otázky mají více podotázek. Některé otázky se zobrazují pouze v konkrétním období.

Řešení – excelovské Power Query

Informace pro tvorbu otázek zadává uživatel v Excelu. Ve stejném souboru se pak použije Power Query na to, že se toto zadání přetvoří do formy, se kterou pracuje appka. Appka ani automate tak už nemusí řešit transformace dat, což je velké zjednodušení.

Alternativou by mohlo být v tomhle kroku využít Power Query např. v Power BI, ale to by znamenalo složitější refreshování.

Problém – nemožnost použít standardní formuláře

V Power Appce jsou formuláře obvykle tvořené komponentou Form. Ta se jednoduše ovládá, ale dává smysl jen pokud máte pořád víceméně stejné otázky. My ale potřebujeme při každém běhu aplikace úplně jiný seznam otázek, jinak strukturovaných, jinak vyplňovaných. Takže co s tím?

Řešení v Power Apps – galerie

Řešením je načíst si podkladová data z Power Automate rovnou do kolekce a tuto kolekci použít jako podklad galerie. Galerie může snadno vypadat jako formulář, přičemž není problém aby každé otázka byla úplně jiná – podle jejich typu. Některá může ukazovat minimální hranici, jiná obrázek, jiná se načítá čtečkou…

Různé fungování pro různé otázky se pak řeší hlavně vlastností Visible. V tom smyslu, že např. komponenta BarcodeReader má vlastnost „Visible“ nastavenou na „true“ jen v tom případě, že se jedná o typ otázky který se načítá scannerem atd.

Do galerie se tedy načtou otázky. Uživatel tím, že vyplňuje „odpovědi“, mění hodnoty podkladové kolekce. Ta se pak celá zase odešle do výsledného „archivu“ – otázky s doplněnými odpověďmi.

Problém – různá zařízení na kterých appka běží.

Potřebovali jsme, aby aplikace běhala na Windows, na Android telefonu i na Microsoft Surface tabletu. Asi si říkáte v čem je problém, protože Power Apps toto běžně řeší automaticky – prostě tvoříte jednu appku a běhá to na všem. Tady to a ale bylo trochu náročnější, protože v procesu je důležité načítání pomocí čteček čarových kódů, které fungují na zařízeních odlišně zařízeních odlišně. Do toho ještě některé čarové kódy byly neobvykle dlouhé a byl problém je číst běžným telefonem, šlo to jen určitými typy čteček.

Další věc je samozřejmě responzivita – appka musí být dobře zobrazená na všem od 4K monitoru po mobil, na všech možných variantách šířek i výšek displeje.

Řešení čtení kódů – více dostupných možností současně

Tohle nemá žádné přímočaré řešení. Prvky, které načítají kódy, se musely vytvořit dvakrát.

• Přes komponentu Barcode.Reader (funguje na Androidu)
• Přes textinputy kam zapisují čtečky kódů připojené přes USB nebo Bluetooth (funguje na Windows a tabletu).

Je to trochu náročné pohlídat, protože se jedna hodnota zapisuje vlastně třemi způsoby (dvě čtečky plus záložní ruční zápis) a je třeba řešit co je priorita. Ale je to docela zvládnutelné.

Trochu kuriózní je, že pokud pustíte aplikaci na zařízení bez čtečky (typicky v prohlížeči), tak bude čtečka generovat testovací hodnotu „1231412“. To je super a na testování se to hodí, ale při vývoji appky je třeba to pohlídat.

Power Appka by uměla i poznat, na kterém OS pracuje (vlastnost Host.OSType na úrovni aplikace, ale nakonec jsme to nevyužili.

Řešení různě velkých displejů – všechno do kontejnerů

Pokud jste zvyklí vyvíjet třeba weby ve WordPressu, může vás překvapit že Power Apps nejsou standardně responzivní. Nicméně řešení je jednoduché – dát všechno do komponenty kontejner a ten už se o to, víceméně, postará.

Kontejnery běžně obsahují další kontejnery a to až v několika vrstvách. Jasně, občas je třeba vyladit odsazení nebo zalamování kontejnerů, ale jinak tohle funguje fakt dobře. Ideální je využít přednastavená rozložení stránky s hlavičkou, obsahem a patičkou a pak to jen lehce ladit podle potřeby.

Problém s obrázky na SharePointu

Speciálním oříškem bylo zobrazit ve formulářích obrázky uložené na SharePointu. To je trochu chyták. Ve Windows se totiž zobrazí i obrázek, jemuž jednoduše zadáte do vlastnosti „image“ link na SharePoint. Android má ale jiné zabezpečení, takže takto zobrazí jen obrázky z volně dostupného webu a ne ze SharePointu.

Řešení je popsané tady

Řešení spočívá v připojení SharePoint knihovny jako zdroje a pak odkazování do něj.

Celková pracnost

Práce zabrala cca 10 MD, rozložených do cca dvou kalendářních měsíců. Nicméně velkou část z toho jsme řešili spíš byznys logiku fungování než technickou stránku věci.

Technologie

Popsané řešení může fungovat v rámci standardních licencí 365, které používá naprostá většina firemních uživatelů – např. Business Basic, Business Standard, E3 atd.

Hodila by se vám podobná appka?

Chtěli byste podobnou appku pro vaši firmu? A máme ji pro Vás vyrobit nebo spíš s vývojem pomoci vám?