Problemy z widocznością relacji N:N w aplikacjach Power Apps sterowanych modelem

Wyróżniający obrazek, który widzicie powyżej, pochodzi serwisu Unsplash.com

Cześć. W dzisiejszym artykule przyjrzymy się pewnemu zachowaniu aplikacji Power Apps*, które może zadziwić niejednego doświadczonego konsultanta. Jak na pewno wiecie – platforma daje nam możliwość tworzenia relacji wiele-do-wielu (N:N) między encjami w tym również między tą samą encją. Problem, który chciałem omówić, przedstawię na przykładzie encji Foo (tak, wiem, jest to bardzo oryginalna nazwa) posiadającej relację do samej siebie.

Poniższy obrazek przedstawia formatkę wyświetlającą dane rekordu „Foo 1”, za pomocą której możemy dodać relację do innych rekordów typu Foo.

Po dodaniu relacji do rekordu „Foo 2” – formatka przedstawia się następująco:

Jak dotąd nie uświadczyliśmy żadnych niespodzianek. Otwórzmy teraz jednak formatkę wyświetlającą rekord „Foo 2”. Ponieważ utworzyliśmy relację typu „wiele do wielu” między rekordami „Foo 1” i „Foo 2” – wydawałoby się, że powinniśmy zobaczyć na formatce „Foo 2” rekord „Foo 1” w tabeli obiektów powiązanych wspomnianą relacją. Tymczasem wcale się tak nie stanie.

Z czego wynika powyższe zachowanie? Okazuje się, że w przypadku relacji N:N w tabeli obiektów powiązanych wyświetlane są tylko rekordy posiadające identyfikator bieżącego obiektu w polu prefix_recordidOne. Pomimo że teoretycznie relacja powinna być „obustronna” – interfejs systemu zachowuje się tak, a nie inaczej.  

Przyznam, że nie jestem pewien, dlaczego system zachowuje się w taki sposób i czy jest do intencjonalne. Wiem natomiast, że opisany sposób działania wprawił już w osłupienie niejednego z klientów, z którymi miałem okazję pracować. Na szczęście istnieje prosty sposób na naprawę tego „problemu”. Wystarczy utworzyć i zarejestrować proste rozszerzenie (plugin), które w momencie utworzenia relacji w systemie – utworzy drugą relację między rekordami, ale z zamienionymi wartościami w polach „xxxOne” i „xxxTwo”.

Przykładowy kod rozszerzeń obsługujących zdarzenia utworzenia oraz usunięcia relacji znajdziecie pod poniższym linkiem:

https://github.com/gashupl/cds-self-referencing-relationship-plugin

Zawiera on 2 klasy pluginów, które powinniśmy zarejestrować dla zdarzeń Associate i Disassociate w systemie. Każdy z kroków obsługujących ww. zdarzenia musi posiadać konfigurację wejściową (Unsecure Config) zawierającą listę relacji N:N, które mają być obsługiwane przez omawiane rozszerzenie.

Przykładowa konfiguracja relacji między rekordami typu Foo (pg_foo) o nazwie pg_foo_pg_foo może wyglądać następująco:

[„pg_foo_pg_foo”]

Kolejne relacje możemy dodawać w powyższej tabeli, oddzielając je od siebie przecinkami.

[„pg_foo_pg_foo”,”pg_account_pg_mycustomentity”]

To tyle na dzisiaj. Miło sobie przypomnieć, że aplikacje Power Apps, Dynamics 365 i platforma Common Data Service to nie tylko rozwiązania typu „no code”. Szkoda tylko, że jej ogromne możliwości dane developerom, musimy czasem wykorzystywać do poprawiania błędów ludzi z Redmond, tak jak w opisanym powyżej przypadku 😉.

* Artykuł dotyczy aplikacji opartych o platformę Common Data Service i sterowanych modelem. Dla uproszczenia będę używał tylko nazwy „Power Apps”

Total Views: 190 ,
Be the first to comment

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *