Hoe kan WeAreFrank! helpen bij dataverlies tussen applicaties en databases als Oracle, MySQL en MongoDB?

Databases dienen als het fundament van je IT-infrastructuur en op die basis bouw je bijvoorbeeld je CRM- of HR-applicaties. Applicaties en databases zijn direct met elkaar verbonden en de data hieruit dienen weer als input voor rapportages en overzichten. Maar wat als de koppeling tussen een applicatie en database niet (goed) werkt? Dan worden berichten met essentiële data niet goed verwerkt en kloppen rapportages ook niet. Schakel dan WeAreFrank! in. We leggen je uit hoe we je kunnen helpen bij dataverlies tussen verschillende systemen en applicaties.


Dataverlies in de praktijk: een voorbeeld 

Stel, je hebt een e-commercebedrijf. Bij het plaatsen van een bestelling in jouw webwinkel worden meerdere gegevens verzameld, zoals de artikelen in het winkelmandje, het afleveradres en de factuur. Die informatie hangt allemaal samen met één order en wordt met verschillende query's weggeschreven in één of meerdere databases. Wat als het fout gaat tijdens het wegschrijven van die data? De stroom of internetverbinding valt uit en er zijn maar enkele orderregels opgeslagen. We lopen dan samen met jou door het proces heen, zowel op functioneel als technisch niveau.

Wil jij in control zijn over je applicatieketen? Download ons stappenplan en ontdek hoe je dat voor elkaar krijgt. 

Download stappenplan

 

Stap 1: functioneel niveau 

Hoe zien de koppelingen tussen jouw webshop, achterliggende applicaties en databases eruit? Worden gegevens in meerdere stappen weggeschreven of slechts in één keer? Wat gebeurt er als er maar de helft van de orderregels wordt opgeslagen en de andere helft niet? We gaan samen door de flow van het plaatsen van een bestelling heen en door die te testen, weten we welke data er uiteindelijk wel of niet in de databases terechtkomen.

Een ander belangrijk aspect op functioneel niveau is het gebruikersgemak. Krijgt de gebruiker feedback als de order succesvol is geplaatst? En wat als de verbinding wegvalt, krijgt de gebruiker dan een foutmelding, zoals 'probeer het nog eens'? Dat is al een simpele oplossing die je helpt besparen op overheadkosten. Je wilt namelijk voorkomen dat klanten met de klantenservice gaan bellen als zoiets voorkomt.

 

Stap 2: technisch niveau

Uiteraard kijken we ook op technisch niveau naar het bestelproces en achterliggende processen. Een webservice communiceert namelijk via HTTP-protocol en dat is niet transactioneel. Terwijl je de data van de order wel transactioneel wilt verwerken. Dat betekent namelijk dat het gehele pakket aan gegevens (adressen, orderregels en de facturatie) in één keer wordt weggeschreven in één of meerdere databases en niet in gedeeltes. Om een transactionele verwerking tot stand te brengen, moet je zowel aan de kant van de browser als de server maatregelen treffen.

Verder wil je niet dat dezelfde gegevens meerdere keren worden opgeslagen, want dan ontstaan er duplicates in je databases. Door ervoor te zorgen dat een bestelling of bericht een uniek ID krijgt, kun je inregelen dat er in het proces wordt gecontroleerd of de bestelling al eerder is ontvangen of niet. Vervolgens kun je weer naar de gebruiker communiceren of de bestelling succesvol is verwerkt. Op die manier voorkom je dat bestellingen maar half of dubbel worden verwerkt én onzekerheid bij de gebruiker.

 

in de toekomst dataverlies voorkomen?

Wanneer gegevens kwijt zijn, is het lastig om deze terug te halen. Maar we helpen je graag bij de inrichting van je IT-infrastructuur en koppelingen met je applicatiedomein om in de toekomst te voorkomen dat data verloren gaat of dubbel wordt verwerkt. Wil je echt grip krijgen op jouw applicatieketen? Check dan deze 5 stappen in de whitepaper, zodat je niet alleen bezig bent met het oplossen van incidenten en problemen, maar proactief kunt handelen op basis van inzicht.

In 5 stappen meer grip 2

 

Wil jij meer grip op jouw applicatieketen?

Gerelateerde artikelen