Uitleg algemene structuur WTell

Algemene Structuur WTell

21 september 2011; Versie:1.0

Uitleg algemene structuur WTell Brondocument C:\WebServer\Handleiding\WTellAlgemeen\WTellStructuurGlobaal.odt

Versiebeheer Versie

Datum

Uitleg

1.0v

21-09-11

1e versie met uitleg globale structuur WTell

Algemeen In 2003 is WTell begonnen als een eenvoudige urenboek applicatie op het ERP-pakket ISAH van ISAH7. Vanaf dat tijdstip is WTell als framework voor verschillende functionaliteiten voor klanten steeds verder gegroeid. In de loop van 2007 kregen klanten steeds meer last van instabiele functionaliteit door een gebrek aan goede structuur. Dit is de reden waarom de gehele opzet van WTell is gewijzigd en modulair van opbouw is gemaakt. Deze ontwikkeling zal de komende jaren verder gaan. Dit document verschaft een globaal beeld van de structuur van WTell. Deze totale structuur is niet bij een klant te vinden. Alleen de delen welke nodig zijn, worden uiteraard geïnstalleerd. Theoretisch zal het gehele framework wel bij elkaar kunnen passen.

Inleiding Dit document is gemaakt voor klanten en samenwerkingspartners om een globaal beeld te geven over de structuur en opbouw van WTell. Hiermee wordt tevens aangegeven dat goed over de verschillende componenten en opbouw is nagedacht. Deze biedt namelijk aan klanten een stabiele en flexibele oplossing, waarvan zij iedere dag ontzettend profiteren.

Organisatie&Adviesbureau “Wilhelm Tell”

1 Van 8



Globale indeling.

Afbeelding 1: Globale indeling WTell Organisatie&Adviesbureau “Wilhelm Tell”

2 Van 8



WTell bestaat globaal uit de volgende lagen, namelijk: 1. GUI. 2. GUI Translator 3. WTell applicatie logica 4. WTell Entities Ad 1 GUI De GUI van WTell geeft aan hoe de gebruiker met de applicatie communiceert. Momenteel kan men middels een webbrowser, desktop en met de mobiele telefoon met WTell communiceren. Hier ervaart de klant de interactie met WTell en wordt de functionaliteit aangeboden. Ad 2 GUI Translator Dit onderdeel draait los van de GUI bij de klant en is in principe verantwoordelijk voor dat de betreffende GUI goed met de WTell Applicatie communiceert. Hier worden de GUI specifieke zaken ingericht en afgehandeld. Er bevindt zich nadrukkelijk geen applicatie of bedrijfslogica in deze laag. Ad 3 WTell Applicatie Logica Om klanten onafhankelijk van de GUI hetzelfde gedrag te kunnen aanbieden is de WTell Applicatie logica geheel onafhankelijk van de GUI geschreven. Dit is het hart van WTell en is verantwoordelijk voor de afhandeling van de regels en de bedrijfslogica van de applicatie. Eigenlijk is dit deel de reden waarom klanten gebruik maken van WTell. Alle logica om gegevens op te halen of op te slaan is nadrukkelijk uit deze laag verwijderd. Ad 4 WTell Entities Losse informatie-eenheden welke door de WTell Applicatie logica worden gebruikt om de logica af te handelen. In principe weet de WTell Applicatie logica niet van welke bron de entities komen. De meeste bronnen van de entities zijn voor de duidelijkheid in de afbeelding weergeven en deze zijn in feite de daadwerkelijke implementatie van een WTell entitie. Bronnen kunnen zijn: bestanden (xml, office, pdf, txt) , mail, databases (Oracle, MySql, MSSQL, Sybase) of een webservice dat communiceert met een extern systeem. Nu de algemene architectuur is geschetst wordt dieper in belangrijkere onderdelen ingegaan:


3 Van 8



WTell GUI

Afbeelding 2: WTell GUI Laag Op dit moment communiceren klanten door middel van verschillende webbrowers (Internet Explorer, FireFox, Chrome) , WTell Mobiel (Aangepaste Webbrowser, Windows Mobile) of de DeskTop (Java Swing) met WTell. De specifieke gedragingen van de verschillende interfaces wordt door de verschillende GUIcomponenten netjes afgehandeld en komen dan de WTell Applicatie logica binnen. Deze tussenliggende laag is dus verantwoordelijk voor het feit dat de WTell Applicatie logica laag zich niet bewust is met welke GUI er wordt gecommuniceerd. Dit maakt het dus erg eenvoudig voor WTell om voor klanten met verschillende GUI's te laten communiceren, vlot nieuwe GUI's aan te bieden of de bedrijfslogica aan te passen. Klanten hoeven dus voor het gebruik van WTell Mobiel als deze reeds WTell door middel van een webbrowser gebruiken niet opnieuw de bedrijfslogica te testen. Deze blijft hetzelfde. Dit scheelt implementatietijd en dus geld. Een groot voordeel van deze splitsing is dat voor de ontwikkeling van de bedrijfslogica alleen hoeft te worden nagedacht om deze zo goed mogelijk aan de organisatie van klanten in te passen. Er hoeft geen rekening te worden gehouden over de interface specifieke wensen en eisen. Deze kunnen namelijk afleiden en tot sub-optimale oplossingen leiden zo is de praktische ervaring in het verleden. Wellicht wordt de verkeerde GUI voor de ondersteuning van het bedrijfsproces gekozen.


4 Van 8



WTell Applicatie logica

Afbeelding 3: WTell Applicatie De WTell Applicatie logica vormt het hart van de applicatie en helpt klanten met de uitvoering van hun taak. Hierbinnen wordt de bedrijfslogica en andere processen vastgelegd en afgehandeld. De 1e versies van WTell maakten de fout om alle klant logica als algemene logica op te beschouwen, waardoor conflicten in functionaliteit optraden. Hierom is dit gescheiden in logica per klant en algemene logica. De algemene logica wordt gedeeld door alle klanten en het gebruik ervan bespaart ontwikkeltijd. De klant specifieke logica bevat de unieke logica van de klant. De WTell Applicatie logica maakt gebruik van WTell Entities welke als interface zijn gedefinieerd. Hierdoor is deze laag zich niet bewust van de bron van deze entities. Dit maakt het eenvoudig om tussen verschillende systemen te communiceren of voor klanten om te wisselen tussen verschillende systemen. Nu zal er in het algemeen niet veel gewisseld worden van de onderliggende systemen, maar het principe is duidelijk. De WTell entities komen vanuit verschillende bronnen, namelijk: •

Navision Connector Bij enkele klanten werken slimme ontwikkelaars welke aan de hand van de gegeven interface prima weten op welke wijze de data aan WTell moeten worden aangeboden.

•

SAP Connector Bij een andere klant worden verschillende pakketten bij verschillende dochters ingezet. Een enkele dochter heeft SAP en voor bepaalde modulen is door een ontwikkelaar een soort SAP connector ontwikkeld.

•

Open Bravo Connector Enkele jaren geleden is Wilhelm Tell bij enkele leveranciers van Open Software langsgegaan met het gegeven dat enkele klanten graag met Open Source zouden willen werken. Voor overleg zou moeten worden betaald en na enkele gesprekken over de implementatie werd verteld dat Wilhelm Tell over


5 Van 8



de brug moest komen. Hoe moet Open Source op deze wijze ooit een commercieel succes worden? Helaas is dus verdere uitbouw voor mogelijkheden voor Open Source leveranciers uitgebleven. Wel is er een connector ontwikkelt met Open Bravo dat als een soort default source wordt gebruikt waaruit WTell communiceert. Bij de betreffende klanten lopen nu enkele slimme jongens rond voor onderhoud. Wilhelm Tell heeft verder besloten na dergelijke vreemde gesprekken zelf geen inhoud aan de uitrol van Open Source ERP te geven, maar houd wel de continuïteit op de achtergrond voor zijn klanten in de gaten. ISAH Connector WTell is gegroeid vanuit maatwerk van ISAH7 van ISAH. Er is natuurlijk een goede ISAH-connector in eigen beheer ontwikkeld. Webservices Enkele jaren geleden was er een hype met webservices, waarmee alles zou kunnen worden gekoppeld. Voor enkele klanten zijn tussen bedrijven of met een CAD-CAM oplossing een soort webservice met andere applicaties gebouwd, waarbij goede afspraken over de interface is gemaakt. Het is een grove webservice zonder echte nauwe interactie. Het grootste probleem met webservices is het onbegrip van het nuttig gebruik ervan bij verschillende leveranciers, waardoor een goede definitie en dus implementatie uitblijft. Webservices is een handige tool, maar je moet hem wel goed inzetten. De enkele keren dat er een goede gesprekspartner bij de externe partij aanwezig was, is er ook tot een goede oplossing gekomen, zoals wel vaker is de techniek geen belemmering.

De reden waarom de functionele Connectors worden behandeld bij de Applicatie logica is dat zij in principe de vertaling verzorgen van de WTell Applicatie logica naar de logica van het betreffende pakket. Hiermee heeft de klant bij de ontwikkeling van zijn bedrijfslogica in principe geen last van eventueel afwijkende logica van het onderliggende pakket. Deze conflicten worden binnen de connectors opgelost. In de praktijk is er nooit een 100% match tussen de wijze waarop het ERP-pakket werkt en de werkwijze van de klant. Helaas blijken medewerkers van ERP-leveranciers vaak binnen de grenzen van hun pakket te denken. De afbakening van de applicatie logica in een afzonderlijke eenheid zorgt ervoor dat WTell voor u niet in deze valkuil valt. Hierdoor kan maximale creativiteit en flexibiliteit worden aangeboden om op bedrijfsprocessen van klanten te matchen zonder meteen tegen specifieke grenzen van een ERP-pakket aan te lopen. Daarnaast is het eenvoudig om dezelfde bedrijfslogica over verschillende connectors te verdelen, waardoor aan de voorkant lijkt alsof de gegevens uit dezelfde pakketten komen, terwijl er in principe verschillende bronnen zijn. In principe wordt de WTell Applicatie logica door de verschillende modulen van WTell doorsneden. Dit betekent dat dezelfde lagen door bijvoorbeeld meetrapporten, urenboeken en planning worden gebruikt zonder dat zij zich daar van bewust zijn. Een reeel conceptueel voorbeeld in de praktijk van dit principe is dat een klant voor urenboeken pakket x gebruikt en voor planning pakket y. Alle data staan in WTell op 1 scherm en de gebruiker is zich niet bewust dat voor hem verschillende pakketten op de achtergrond draaien. Uiteraard zijn niet alle WTell Entities over alle connectoren ontwikkeld. Alleen de WTell Entities welke nodig zijn voor het leveren van functionaliteit met het betreffende pakket zijn ontwikkeld.


6 Van 8



WTell Entities

Afbeelding 4: WTell Entities

Afbeelding 5: WTell Entities De WTell Entities worden gevuld vanuit de verschillende connectors of eventueel een zelfstandige bron. In de WTell Entities afbeelding staat de wijze waarop deze worden gevuld. De Connectoren welke zijn beschreven bij de WTell Applicatie zijn in principe functionele connectoren bij de gegevens gaat het meer om technische connectoren. •

WTell Mail Connector Deze connector is verantwoordelijk voor het lezen, ophalen en versturen van mails. Tevens worden bij enkele klanten emails gebruikt als uitwisselingsmechanisme tussen systemen.

•

WTell File Connector Deze connector is verantwoordelijk voor het lezen, ophalen en opslaan van bestanden in het operering systeem. Het type systeem Windows, Linux,etc maakt in principe niet uit.

•

WTell XML Connector XML is een goede wijze om gegevens te structuren volgens vaste afspraken en logica. De taak van de WTell XML Connector is om deze logica te bewaken en om gegevens op te halen en weg te schrijven. In deze rol wordt nauw samengewerkt met de WTell File Connector

•

WTell Database Connector Deze connector is verantwoordelijk voor het afhandelen van gegevens over databases. Vanuit het Sybase maatwerk in het verleden werd tot 2008 veel met SQL en Stored Procedures gewerkt waarvan de performance nog steeds superieur is. Wel wordt steeds meer gebruik gemaakt van een standaard wijze om gegevens op te halen en op te slaan middels een object koppeling. Hiermee is het schrijven van specifieke SQL-code voor het ophalen en opslaan van WTell entiteiten niet meer nodig. In principe wordt voor nieuwe functionaliteiten gebruik gemaakt van de object koppeling,


7 Van 8



tenzij performance of andere praktische zaken dit in de weg staat. Veel oude stored procedures zijn omgezet naar de object koppeling om het update proces van WTell te verbeteren en minder afhankelijk te zijn van aanpassingen van leveranciers in de database. Deze vermindering van de benodigde stored procedures vereenvoudigd ook het update proces van de verschillende software pakketen welke WTell voeden. Dit neemt belemmeringen weg en verlaagt kosten van klanten om deze pakketten te updaten sterk. Conclusie Dit document geeft een goed beeld van de structuur van WTell welke in de loop der jaren vanuit praktijk ervaring is ontstaan. WTell draait uiteraard in volle tevredenheid bij verschillende klanten. Zelf beleeft Wilhelm Tell ontzettend veel plezier aan een goede structuur, waarmee voor klanten in korte tijd tot leuke oplossingen is gekomen en zij goed en soepel kunnen worden ondersteund. Dit is in deze tijd het allerbelangrijkst. Vaak komt Wilhelm Tell bij nieuwe klanten geniale oplossingen van ontwikkelaars tegen, waarbij de gehele code als spaghetti in elkaar is gebouwd of sterk binnen 1 programmeertaal, ERP-pakket of framework wordt gedacht. Je moet van bepaalde beperkte zaken uitgaan om zo kennis en ervaring te verwerven, Wilhelm Tell gebruikt voornamelijk Java als programmeertaal, maar wel open blijven staan van goede mogelijkheden van alternatieven. Een gebrek aan openheid leidt dikwijls tot eiland automatisering en inflexibele systemen, zoals u in de praktijk wellicht zult ervaren. Wilhelm Tell heeft ook grappige ervaringen met verschillende leveranciers met hun beperktheid van denken en hierdoor het missen van kansen bij zijn klanten. Iedereen schept zijn eigen grenzen lijkt het wel vaak. Het zou toch mooi zijn dat het anders is en de automatisering uw bedrijf beter en soepel volgt. In principe is digitale programmatuur en informatie vrij eenvoudig te wijzigen en worden belemmeringen opgeworpen door mensen met hun gedragingen, cultuur, kennis en ervaring. Zelf streeft Wilhelm Tell dagelijks om uw automatisering perfect aan uw wensen te laten voldoen, zodat uit de techniek het maximale wordt gehaald en u zich als klant optimaal kunt richten op uw eigen bezigheden om het beste voor uw klanten te bereiken.


8 Van 8

Uitleg algemene structuur WTell

Recommend Documents