Připojování jiných map join-mapp

Substruktura join-mapp slouží pro připojování jiných map, což umožňujě rozpad jednoho typu dokumentu do více typů dokumentů na výstupu či naopak. V podstatě jde o slučování či rozdělování mezi různými počty typů dokumentů v jedné instanci, tedy při typové neshodě vnější a vnitřní informační struktury.

Některé typy neshod můžeme vyřešit pomocí podmínky v kmenové mapě, tedy správným nastavením podmínek input-on / output-on v substruktuře mapp-to-app definice interního dokumentu. Někdy se však bez spojování map neobejdeme. Význam nejlépe ukážeme opět na příkladu. Uvažujme o smlouvě se zákazníkem, kdy v systému flexideo máme dva druhy smluv, každou evidovanou v jiném typu (což téměř nikdy není příliš šťastné řešení XDS) a máme tak poskytovani_sluzeb a dodavky_zbozi jako dva typy dokumentů reprezentující smlouvy uzavřené se zákazníky. V externí aplikaci však máme možnost evidovat smlouvy v jediné evidenci typu smlouva. Nejprve se pojďme vzít jednodužší variantu A:

A) Pokud pro každou položku uvnitř systému flexideo bude existovat i jedna "venku", spojování map nepotřebujeme. Pokud tedy máme 2 smlouvy o poskytování služeb a 3 smlouvy dodavatelské na straně jedné a má vzniknout 5 externích smluv, pak si vystačíme se samostatnými mapami u obou interních typů, kdy jak služby tak i zboží budou v kmenu mít substrukturu mapp-to-app namířenou na externí smlouvu. Pak už jen záleží na využití sestavených map v nastaveních výměny dat, která se provádějí v rámci nastavení transformačních procesů. Jde jen to to při importu dat nastavit dostatečné rozlišení externí smlouvy, zda se má uložit jako "dodavatelská" nebo jako "poskytovatelská" pomocí podmínky input-on kmenového uzlu mapp-to-app. Totéž by platilo i při opačné situaci, kdy bychom měli uvnitř systému flexideo definován jediný typ smlouva a v externí aplikaci by byly evidovány dva či více typů. Rozdíl by byl pouze v tom, že dva či více uzlů mapp-to-app by byly definovány v jednom interním dokumentu, po každé s jinou podmínkou ouptupt-on.

B) Kdybychom však měli situaci, že jeden externí typ smlouvy může pojmout oba typy interní, tj. jednou smlouvou se sjednávají jak dodávky zboží, tak i případné služby, je situace složitější. Pak již neplatí, že 2 + 3 = 5, ale můžeme klidně dojít k výsledku 3 nebo 4! To jest máme tři nebo čtyři zákazníky a s nimi máme uzavřen určitý druh smlouvy, který buď zahrnuje zboží nebo služby nebo také obojí. Jde tedy o zmíněné různé dělení v jedné instanci. To je jedna z možností využití spojování map pomocí substruktury join-mapp. Opět si definujeme kmenové mapp-to-app v obou interních typech poskytovani_sluzeb a dodavky_zbozi a do každé této substruktury vložíme propojení map, tj. do obou mapp-to-app přidáme join-mapp s odpovídajícím vyhledávacím výrazem připojované instance join-output-where:

<DocumentDef>
<name>poskytovani_sluzeb</name>
...
<mapp-to-app application="moje-aplikace" document="smlouva" purpose="sml">
<join-mapp from-definition="dodavky_zbozi" purpose="sml">
join-output-where="::/klient/id = /klient/id"
/>
</mapp-to-app>
...
</DocumentDef>
...
<DocumentDef>
<name>dodavky_zbozi</name>
...
<mapp-to-app application="moje-aplikace" document="smlouva" purpose="sml">
<join-mapp from-definition="poskytovani_sluzeb" purpose="sml">
join-output-where="::/klient/id = /klient/id"
/>
</mapp-to-app>
...
<DocumentDef>

Povšimněte si podmínek join-output-where u obou map, které vybírají interní instanci pro připojení do externí struktury z předpřipravených výchozích dat. Interní dokumenty mají oba shodně definovánu oblast klient a je využíván interní jednoznačný číselný identifikátor klienta id. Z výrazů je pak patrné, že vlastnost join-output-where odkazuje logicky do interních typů a to jak do místního, tak také do zdrojově vzdáleného typu. Odkaz do vzdáleného typu je indikován zdrojovou instrukcí :: vyskytující se i v jiných, nejen mapovacích, vlastnostech.

Pokud bychom měli opačnou situaci s jedním interním dokumentem smlouva a dvěma dokumenty externími, které je při exportu nutno dělit a při importu slučovat, použili bychom na místo vlastnosti join-output-where vlastnost join-input-where. Dejme tomu, že externí aplikace bude pro označení subjektu používat uzel zakaznik a také nemáme interní číselný identifikátor id a musíme si vystačit s IČ daného subjektu. Pak bude mít připojovací podmínka následující podobu:

join-input-where="::/zakaznik/ic = /zakaznik/ic"

Substrukturu join-mapp můžeme uvádět i s podmínkami output-on, input-on, ty mají však i zde význam výběru či nevýběru připojovací metody, neplní tedy úlohu výběru instancí. Nejprve je vždy rozhodnuto o tom, jaké mapovací struktury budou použity pomocí podmínek ...put-on, můžeme mít tedy několik join-map, které chceme pro různé účely použít a terpve potom v rámci již rozhodnutého typu připojení je na výchozí data použit jejich instanční výběr pomocí výrazů zadaných v join-output-where a join-input-where.

---

Identifikace mapované aplikace applicationVlastnost autocompleteMožnost rozšířit mapováním obecnou oblast custom-x-commonIdentifikace typu dat mapované aplikace documentMetoda pro vstup dat input-methodMetoda pro výstup dat output-methodJednoznačné jméno (účel) mapy purposeVolba pro zahrnování kmenového uzlu root-areaPodmínka pro vstup dat input-onNastavení vstupních parametrů input-paramsPoužitelnost mapování pro určitý režim modeSpecifikace obalu packPárování externích instancí na interní pair-according-toPodmínka pro výstup dat input-onNastavení výstupních parametrů output-paramsVýběr připojovaných vstupních dat join-input-whereVýběr připojovaných výstupních dat join-output-wherePřipojování jiných map join-mappZákladní mapovací odkaz pro segmenty refInstanční specifikace uzlu v obalu multi-node-refUrčení rodičovského uzlu obalu parent-node-refNastavení nemapovaných údajů unmappedIdentifikace jmenného prostoru uriSpecifikace jmenných prostorů xml-ns

---