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 vsubstruktuř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ámedva 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žnostevidovat 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 2smlouvy 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í aplikaciby 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ělisituaci, ž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 nebo4! 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í substrukturyjoin-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 oboumapp-to-app přidáme join-mapp s odpovídajícím vyhledávacím výrazem připojované instance join-output-where:
poskytovani_sluzeb ... join-output-where="::/klient/id = /klient/id" /> ... ...
dodavky_zbozi ... join-output-where="::/klient/id = /klient/id" /> ...
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 oblastklient 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ěmadokumenty 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 uzelzakaznik 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žitjejich instanční výběr pomocí výrazů zadaných v join-output-where a join-input-where.
Nastavitelné vlastnosti uzlu join-mapp
Substrukturu join-mapp je možné specifikovatnásledujícími vlastnostmi:
Potenciální vlastnické uzly
Substrukturu join-mapp je možné uvést u následujících uzlů:
Možní potomci uzlu join-mapp
Substrukturu join-mapp není možné doplňovat žádnýmipotomky.