Wanneer je een verbinding wilt maken met een webpagina vanuit een andere module, mag je die pagina niet openbaar maken en ernaar verwijzen. Dat zou namelijk een overtreding zijn van de regel 'Geen onderlinge verwijzingen tussen End-user- of Orchestration-modules', zoals hier omschreven: Validating your application architecture. Dit artikel legt stap-voor-stap uit hoe je verwijzingen kunt maken conform de regels voor de architectuur.

Onderstaande afbeelding illustreert dat als A naar B verwijst, A onnodig het cluster D, E, G overneemt.

We lichten de stappen toe met een voorbeeld, door het maken van een link naar het scherm OSMDb Cinemas vanuit de module HowToLinkToWebScreens.

Open de module OSMDb en open de Mainflow. Sleep een entry-node naar de Mainflow, noem deze CinemasEntry en verbind de node met de web pagina Cinemas. Publiceer de module met één klik (F5).

Open de module HowToLinkToWebScreens en open het venster Manage dependencies (Ctrl + Q). Voeg de verwijzing GetEntryUrl uit de module HTTPRequestHandler toe.
Maak een nieuwe ServerAction (Ctrl +N) en noem deze CinemasGetEntry. Voeg een uitvoerparameter van het type tekst toe en noem deze EntryUrl. Stel de functie in op Yes.

Open de webpagina vanuit de locatie waar je de link wilt maken. Voeg een link-widget toe aan de pagina en laat deze verwijzen naar ExternalUrl. Stel de parameter Url in op CinemasGetEntryUrl().

Deze methode kan ook worden gebruikt voor pagina’s met parameters. Stel dat we gegevens in onze module hebben die een CinemaId bevatten.

We kunnen dan gemakkelijk een link naar het CinemaDetailScreen maken; deze methode kan zelfs worden gebruikt voor een pop-up-link en is heel geschikt voor het maken van een menuapplicatie zonder verwijzingen naar de UI-modules. In dat geval moeten we een invoerparameter toevoegen aan de ServerAction en de GetEntryUrl.

Door bovenstaande stappen te volgen, hebben we een architectuur gemaakt waarin vanuit andere modules naar UI-modules wordt verwezen, zonder onderlinge verwijzingen:

Door GetEntryUrl te gebruiken, voorkom je verwijzingen naar End-user- of Orchestration-modules. End-user- en Orchestration-modules moeten in principe geen herbruikbare services bieden. Daarmee wordt gewaarborgd dat ze op de goede manier van elkaar gescheiden zijn en verschillende levensduren kunnen hebben. En daarmee verschillende versietempo's als gevolg van verschillende ‘sponsoren’ of projectteams.

Dit is van cruciaal belang omdat End-users en Orchestrations bovenaan in de hiërarchie staan. Een verwijzing naar dergelijke modules brengt vaak een gigantische verzameling aan indirecte afhankelijkheden met zich mee vanuit de onderliggende lagen.

 Het wijzigen van de naam van een module, webpagina of de parameters daarvan resulteert in een niet meer werkende link (URL). Net als wanneer je vanuit een externe website linkt naar een pagina, die vervolgens wordt gewijzigd of verwijderd.

• De functie <screenentry>GetEntry() kan worden verplaatst naar een core-services-laag om het effect van wijzigingen te verminderen. Let er wel op dat je niet alle GetEntry-functies in één module plaatst. Anders krijg je een module  waar alle schermmodules van afhankelijk zijn en zonder losse koppeling (‘dependency spider’) . Het is beter om ze per functioneel gebied te groeperen in library-modules.

• Je kunt de URL’s ook in een statische entiteit in een core-service-module zetten. Dit leidt eveneens tot een ‘dependency spider’ en vaak ook tot slechtere prestaties omdat voor iedere entry het entity-record moet worden opgehaald. Dit geldt vooral wanneer dit wordt toegepast bij grote menu's.