Regression Suite Automation Tool, a day in a live
We have been working for a while now with RSAT at various customers, it is stable, but we see sometime small glitches in user experience. In general, what is happening, if you haven’t maintained/used it for a while (for instance when during implementation RSAT is configured and used (for instance as provisioning tool), but then not actively monitored for some time) and a consultant or customer starts using it does not work (as expected). So, let us address some topics you should check before (re)using RSAT. Below is a list based on using RSAT for the last 2 years.
LCS (Lifecycle Services) Project Azure trust expires (every year)
There is a trust between DevOps and LCS, the maximum trust time is one year.
Getting a new token at: https://XXX.visualstudio.com/_usersSettings/token
In case the access token is expired, update it from LCS
For more information about integration of LCS and Dev Ops please read Is your Business Process Modeler updated? – Kaya Consulting (kaya-consulting.com)
Are the soap names still, correct?
Unbelievably, there are a lot of incorrect solutions in the MS communities, with all distinct kinds of suggestions, starting from adding only soap or at the wrong place in the URL. The correct location is:
• Tier 2 XXXXXaossoap.sandbox.operations.dynamics.com
• Tier 1 XXXXXaossoap.cloudax.dynamics.com
Limitation on the test user (the consultant test partner account)
The test user must be active in the tenant domain of the customer. In general, always try to avoid using non-customer tenant users as also uploading the task recording directly into LCS, has similar issues. The tenant domain is visual in D365 at right top, click the question mark and about, tab page licenses.
Validate the certificates
And those are the nasty ones, I have seen a lot of Non-RTFM issues here. So, let us start addressing them by environment type. We will first start Microsoft Management Console for validating the certificates.
• Start mmc.exe
• We add the snap ins for certificates; for the current user and local computer.
It is wise to save this console setup after validating and fixing!
Tier 1 dev box
When you create a certificate for a Tier 1 and look at the pulldown, we can agree, no clue, what is meant here?
Adding a user-friendly meaningful name to the certificate will help you, this can be done by pressing the right mouse and selecting properties.
Meaningful names will result in clear names on the pull down for the Thumbprints.
Wif.config
There is a widespread misconception that pressing New in the RSAT tool also adapts the config file on the remote dev box. Sorry, technical consultants can perform miracles, but this is not one of them. So please open your remote desktop to the Dev Box and validate it!
Tier 2 environments
Be aware that platform updates also update the RSAT certificates. Last week I checked all on Monday and on Friday constant complaints, it is not working. That they did a platform update during that week, they forgot to tell me 🙁
Maintain Certificates RSAT Tool
Working with the Maintain Certificates RSAT Tool. It is not perfect yet. The Tier 1 and production should not appear on the list.
The user-friendly meaningful names are missing (but you know how to fix this now)
So, you change to the meaningful name. But it is still not working. You get the next error.
It took me some time to figure out this one. Please look at the next pictures on how to resolve this. I think MS will fix this in their next release.
And if we compare it with the certificate I imported the old way, we see a difference. With below certificate RSAT can pull a token.
Microsoft is on the right track with the Maintain Certificates RSAT Tool. So, we follow Frank Dahl and support him with valuable feedback.
Conclusion
Despite the above, I am still a happy user of RSAT!
For more details about RSAT please look at.
DataALM in een Dynamics 365 Finance & SCM omgeving – Deel 2 van 2
Deze blog bespreekt de mogelijkheden voor de automatisering van post-refresh cleanup taken (na een database restore) via scripting.
DataALM in een Dynamics 365 Finance & SCM omgeving – Deel 1 van 2
Deze blog bespreekt Microsoft’s LCS ”Self-Service Database Refresh” voor het terugzetten van een productiedatabase in een sandboxomgeving.
Zo houdt u controle over Customer balances (Deel 2)
In deze blogreeks helpen we u op weg naar een “best practice” die u kunt gebruiken om controle te houden over uw klantenbalansen in D365 F&O.
Zo houdt u controle over Customer balances (Deel 1)
In deze blogreeks helpen we u op weg naar een “best practice” die u kunt gebruiken om controle te houden over uw klantenbalansen in D365 F&O.
Dynamics AX 2012 naar D365 F&O kookboek
Dynamics AX 2012 naar D365 F&O kookboek
Ik heb al heel wat datamigraties gedaan, maar om eerlijk te zijn houd ik niet van de volledige data- en codemigratie.
Dus ja, ik doe de codemigratie, maar de gemigreerde code is vanuit mijn oogpunt slechts een library met mogelijke herbruikbare oplossingen. We refactoreren deze code altijd, maar dat zal een impact hebben op de datamigratie. Dus, hoe kunnen we het op de juiste manier doen? We maken de nieuwe masterdata, en als deze taak is voltooid, moet je migreren naar de volgende topics. De truc is dat je ook de customizations van bovenstaande topics moet toevoegen op de data-entiteiten. Deze truc werkt zelfs voor AX 2009. Dus, hier is een overzicht van alles wat geëxporteerd moet worden.
Wat moet je exporteren?
- Customers
- Sales tax exempt numbers
- Customer definitions
- Customer details V2
- Customer bank accounts
- Customer postal addresses
- Global address book V2
- Contacts V2
- Party contacts V3
- Vendors
- Sales tax exempt numbers
- Vendors V2
- Vendor bank accounts
- Vendor postal addresses
- Global address book V2
- Contacts V2
- Party contacts V3
- Products
- Products V2
- Product variants V2
- Product master configurations
- Released products V2
- Released product variants V2
- Sales orders remain delivery
- Sales order headers V2
- Sales order lines V2
- Purchase orders remain delivery
- Purchase order headers V2
- Purchase order lines V2
- Trade agreements
- Excel plug in
- On hand (Available + reserved)
- Movement Journal and Excel plug in
- Vend trans Open
- General Journal and Excel plug in
- Cust Trans Open
- General Journal and Excel plug in
- Bank accounts
- General Journal and Excel plug in
- P&L balance
- General Journal and Excel plug in
Als je meer onderdelen moet importeren, bekijk dan de templates. Dit is een goed begin.
Data-entiteiten vs SQL Views
Zoals je kunt zien, zijn er veel Excels te maken. Dus kunnen we dat automatiseren? Ja, dat kan! Maar je moet begrijpen hoe het data import framework werkt in D365FO. Je moet weten dat elke gegevensentiteit ook een SQL View is. Dus, start een Tier 1 dev box en exporteer die views naar een SQL create script. Laten we eens kijken naar de volgende voorbeelden.
In de volgende afbeelding kun je zien dat de SQL View eruit ziet als de Visual Studio Entity.
Nu moet je de view exporteren vanuit SQL Studio.
Let’s export, YEH!!
De volgende stap is het importeren van deze views in AX 2012. Ik raad sterk aan om de view-namen te veranderen naar de functionele namen uit de bovenstaande lijst (gebruik een underscore voor de spaties). Na het aanmaken van al die views in AX 2012, is de laatste stap het maken van een exportbestand in Excel-format.
Het Source-format is je AX 2012 Prod Database en je target is Microsoft Excel. Selecteer je views.
In dit voorbeeld heb ik de view-namen niet hernoemd naar de functionele entiteitnaam (voorbeeld is van het begin van mijn leercurve 😉). En uiteindelijk krijg je een mooie Excel met meerdere tabbladen, die je eenvoudig kunt kopiëren naar je import source-bestanden. Gebruik bij voorkeur functionele namen, zodat de tabbladen meer in lijn zijn met de import Excel-bestandsnamen.
Let’s import
Nadat je de tabbladen naar hun respectievelijke Excel-sheets hebt gekopieerd, deze terug in het zip-bestand hebt gekopieerd en ten slotte hebt geïmporteerd, zal het er zo uitzien. (Opmerking: het zip-bestand wordt gemaakt door eerst de data uit D365FO te exporteren. Dit zal resulteren in het lege Excel-bestand in het zip-bestand.)
Een stukje advies
- Maak consistentiequeries in AX 2012 en bekijk onderstaande topics. Het is beter om ze hier te bekijken dan wanneer je het in D365FO importeert.
- Is de factuurrekening van de klantrekening ook gemigreerd?
- Is de primaire leverancier van het artikel gemigreerd?
- Zijn alle contactpersonen gemigreerd die gerelateerd zijn aan de klanten en leveranciers?
- Hebben we verouderde adressen op de verkoop- en inkooporders?
- Dit gebeurt wanneer het adres van de klant of verkoper wordt gewijzigd en daarna de verkoop- of inkooporder niet meer wordt bijgewerkt.
- Zijn alle klanten of verkopers met betrekking tot klanten- en verkooptransacties open gemigreerd?
- Datatijd: Natuurlijk zal deze view niet overeenkomen, dus je moet de queries aanpassen. Zaken als van en tot datum
- Een ander pijnlijk ding is de table inheritance, de tabel ID in D365FO kan anders zijn dan in AX 2012
- De relation roles waren ook zoiets
- Cust & vend trans open scope
- Alleen open sales lines
- Alleen open purchase lines
- Ja, we kunnen een beetje FIFO simuleren. De Invent Sum tabel heeft een Modified Date Time. Dit zegt ons wanneer dat item voor de laatste keer werd gewijzigd.
- Dus ongelooflijk oude Date Times zullen er zo uitzien in uw warehouse:
- Out of the box kan het sales line nummer niet worden geïmporteerd, dus moet je de Sales order lines V2 Entity uitbreiden. Je moet ook kijken naar de markering tussen de verkoop- en de inkoopregels. Mijn advies is om eerst de Inkoopregels te importeren, en daarna de verkoopregels. Zoek op de verkoopregel-entiteit naar de gerelateerde inkoopregel. Wanneer de inkoopregel niet gevonden wordt, betekent dit niet dat het een fout is, omdat de gerelateerde inkoopregel overgeslagen kan zijn bij de datamigratie. Zorg er ook voor dat de formules beschikbaar zijn voordat je de verkoop- en inkoopregels importeert, anders hebben uw voorraad transactiewaarden de verkeerde waarden…
Als er iets fout gaat en je de fouten moet herstellen, kan een eerdere blog je helpen om je fouten naar Excel te exporteren en ze dan weer te importeren.
Power BI-rapporten genereren met Microsoft Dynamics-data
Power BI-rapporten genereren met Microsoft Dynamics-data
Power BI is een verzameling softwareservices, apps en connectors die samenwerken om uw niet-gerelateerde databronnen om te zetten in samenhangende, visueel aantrekkelijke en interactieve inzichten. Uw data kan een Excel spreadsheet zijn, of een verzameling van cloud-based en on-premises hybride data warehouses.
Wij gebruiken de Power BI Desktop om rapporten te maken. In deze blog laten we u zien hoe u dit kunt doen met Microsoft Dynamics-data. Met Power BI Desktop kunt u:
- Verbinding maken met data, inclusief meerdere databronnen.
- De data vormgeven met queries die inzichtelijke, overtuigende datamodellen bouwen.
- De datamodellen gebruiken om visualisaties en rapporten te maken.
- Uw rapportbestanden delen zodat anderen ze kunnen gebruiken, erop kunnen voortbouwen en ze kunnen delen. U kunt Power BI Desktop .pbix-bestanden delen zoals alle andere bestanden, maar de sterkste methode is om ze te uploaden naar de Power BI-service.
Volg de onderstaande stappen om Power BI-rapporten te maken op basis van Microsoft Dynamics-data.
Deel 1: Een database opzetten (BYOD – Bring your own database)
Waarom is het nodig om BYOD te hebben? Dit zal helpen om een replica te maken van de Microsoft Dynamics Database en het zal ook helpen om toegang te krijgen tot de originele database, wat een probleem kan opleveren als de gegevens zijn gewijzigd. Dus, we nemen onze eigen database mee en exporteren alleen de tabellen met data die we willen zien in Power BI rapporten.
Voor dit voorbeeld zullen we gebruik maken van SQL database in Azure. (Aangezien de database zich in de cloud bevindt, zal het gemakkelijk zijn om op elk moment verbinding te maken met de database). Het is dus beter om de database in de cloud te gebruiken. We moeten een SQL server en database creëren, die we zullen gebruiken om gegevens van Dynamics op te slaan. Zie deze link om een nieuwe SQL server en database aan te maken in Azure. Zodra de Azure SQL database is aangemaakt, kunnen we de database openen in SSMS (SQL Server Management Studio).
Deel 2: Exporteer de data van Microsoft Dynamics naar Azure SQL
Stap 1: Meld u aan bij Microsoft Dynamics en selecteer Data management in het menu van de workspace. Selecteer in Data management de optie Configure entity export to database.
Stap 2: Maak een verbinding met de BYOD-database door op Nieuw te klikken en de connection string van de SQL-database in te voeren. Het format voor de connection string is als volgt:
Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;
Stap 3: Publiceer de entiteit die gekopieerd moet worden in Azure SQL. Publish zal de structuur van de tabel aanmaken in de Azure SQL DB. Klik op de Publish knop.
Vink het selectievakje aan voor de entiteiten die moeten worden gepubliceerd en klik op de Publish knop.
Een pop-up melding zal verschijnen. Dit betekent dat de job gepland is.
Zodra de publish job succesvol is, zullen we voor de entiteiten Yes zien in het Published veld. U krijgt een melding zodra de job succesvol is afgerond.
We hebben nu het schema aangemaakt in de Azure SQL database. Om dit te bekijken kunnen we SSMS openen en de server refreshen, we zullen dan het schema van de tabel in de database te zien krijgen.
Stap 4: Nu kunnen we de data van Microsoft Dynamics naar Azure SQL pushen. In Data Management, klik op Copy into legal entity.
Op deze pagina kunt u 1 entiteit of meerdere entiteiten selecteren om data naar BYOD te pushen.
Zodra u alle entiteiten hebt toegevoegd, kunt u op de knop Export klikken. Wanneer op de Export-knop wordt geklikt, wordt er een job aangemaakt en wordt alle genoemde entiteitdata van Dynamics naar BYOD gepushed.
Er komt een pop-up melding. Dit betekent dat de batch-job is ingepland. U krijgt een melding zodra de job succesvol is afgerond.
Refresh de SSMS en u zult zien dat de data in de tabel staat.
Deel 3: Ontwikkel Power BI-rapporten op basis van de data in BYOD
Gebruik Power BI Desktop om Power BI-rapporten te ontwikkelen. U kunt Power BI Desktop hier downloaden.
Stap 1: Laad de gegevens naar Power BI Desktop.
Nadat u Power BI Desktop hebt geopend, selecteert u de knop Get data en klikt u op More. Er verschijnt een pop-up waarin u Azure kunt typen en Azure SQL-database kunt selecteren en op de knop Connect kunt klikken.
Voer de Server en Database gegevens in en klik op OK.
Selecteer de tabel die u wilt laden in Power BI en klik vervolgens op de knop Load.
Stap 2: Zodra de data geladen is, kunnen we de data transformeren. Om dit te doen, klik op de knop Transform data hieronder.
Wanneer op de knop Transform data wordt geklikt, wordt een nieuw venster geopend. Vervolgens kunt u de data die u hebt wijzigen. U kunt bijvoorbeeld de velden verwijderen die u niet wilt gebruiken en enkele berekeningen uitvoeren.
Selecteer de kolommen die u wilt verwijderen en klik vervolgens met de rechtermuisknop en selecteer Remove Columns.
Zodra de data getransformeerd is, kunt u alle stappen die genomen zijn om de data te transformeren aan de rechterkant zien in de sectie APPLIED STEPS. Klik dan op de knop Close & Apply om de wijzigingen toe te passen.
Stap 3: Maak het Power BI-rapport.
Zodra het Power BI-rapport klaar is, kunt u het publiceren. Hiermee wordt het rapport beschikbaar gemaakt voor het Power BI Dashboard.
Met deze laatste stap sluiten we deze blog af. Hopelijk heeft het u geholpen bij het maken van Power BI Rapporten met uw Dynamics-data. Tot in de volgende blog!
Bron:
https://docs.microsoft.com/en-us/power-bi/fundamentals/desktop-getting-started
Online Invoicing met EM/ER
Wat is Online Invoicing, ook bekend als Electronic Invoicing of e-Invoicing, en hoe kan het worden toegepast voor uw klanten in Dynamics 365 for Finance and Supply Chain Management? Online factureren is niets anders dan het elektronisch verwerken van digitale facturen in een boekhoudsysteem vanuit een geautomatiseerd systeem, in ons geval D365FSCM. Voor het afhandelen van online facturatie in D365FSCM hebben we twee soorten functionaliteiten beschikbaar die nauw met elkaar samenwerken: Electronic Messaging (EM) en Electronic Reporting (ER). In deze blog vertel ik hier meer over en beschrijf ik een scenario dat we hebben geïmplementeerd voor een van onze internationale klanten.
Electronic Messaging
Recentelijk hebben de regeringen en wetgevende autoriteiten van verschillende landen over de hele wereld rapportage-eisen ingevoerd voor ondernemingen die in die landen zijn geregistreerd. Het doel van de eisen is om het mogelijk te maken data te verkrijgen van die bedrijven in een elektronisch formaat, rechtstreeks uit de systemen waar het werd geboekt, opgeslagen en verwerkt.
De EM-functionaliteit in D365FSCM is bedoeld om dit soort elektronische interoperabiliteit tot stand te brengen tussen D365FSCM en de systemen die regeringen en wetgevende instanties aanbieden voor het rapporteren, indienen en ontvangen van officiële informatie.
Enkele basisbegrippen in deze EM-functionaliteit zijn:
- Elektronisch bericht: een rapport of opgave die moet worden verzonden, zoals een rapport dat naar een belastingkantoor wordt gestuurd.
- Elektronisch bericht-items: records die in het gerapporteerde bericht moeten worden opgenomen.
- Elektronische berichtverwerking: een keten van gekoppelde of niet-gekoppelde acties die moeten worden uitgevoerd om de vereiste data te verzamelen, rapporten te genereren, data op te slaan in Azure Blob storage, rapporten buiten het systeem te verzenden, antwoorden van buiten het systeem te ontvangen en de database bij te werken op basis van de informatie die wordt ontvangen.
De volgende afbeelding toont de data flow voor EM:
Electronic Reporting
De EM-functionaliteit is nauw geïntegreerd met de ER-module, die u kunt gebruiken om formats voor de elektronische berichten te configureren in overeenstemming met de wettelijke vereisten van de verschillende landen. ER wordt beschouwd als het belangrijkste standaard instrument ter ondersteuning van lokalisaties en stelt u in staat deze formats gedurende hun levenscyclus te beheren. Aangezien de eisen van overheidsinstanties regelmatig kunnen veranderen, betekent dit dat in die gevallen de formats voor elektronische berichten moeten worden aangepast.
In plaats van het uitbreiden van de code voor D365FSCM om te voldoen aan de wet- en regelgeving voor verschillende landen, kan elke zakelijke gebruiker deze ER-tool eenvoudig configureren en gebruiken zonder ook maar één regel code te hoeven gebruiken. Hoewel… dit is wat Microsoft beweert, en zoals gebruikelijk zijn de zaken iets ingewikkelder dan dat. De hulp van een functioneel consultant en een ontwikkelaar is bijna altijd nodig om alles werkend te krijgen!
Verwerking van Online Invoicing
Dus hoe wordt EM/ER toegepast voor de verwerking van online facturering? Zie de acties in het volgende schema:
De EM-functionaliteit ondersteunt de volgende scenario’s voor het online factureringsproces:
- Verzamelen en verwerken van informatie uit een databron (een D365FSCM-tabel) als berichtitems.
- Sla aanvullende informatie op en evalueer verschillende waarden door specifiek gedefinieerde executable classes in relatie tot berichten en berichtitems aan te roepen.
- Verzamel informatie die is opgehaald in berichtitems, splits die informatie op per bericht, en genereer rapporten die in de bijbehorende ER-formats staan.
- Verzend de gegenereerde rapporten naar een webservice door gebruik te maken van beveiligingsinformatie die is opgeslagen in de Azure key vault.
- Een reactie van een webservice ontvangen, de reactie interpreteren en gegevens in D365FSCM bijwerken waar nodig.
- Opslaan en bekijken van alle gegenereerde rapporten.
- Opslaan en bekijken van alle loginformatie die is gerelateerd aan acties die worden uitgevoerd voor een bericht of berichtitem (opgeslagen als bijlagen die zijn gekoppeld aan deze berichten en berichtitems).
- De verwerking controleren door middel van verschillende berichtstatussen en berichtitemstatussen.
OK, nu we wat algemene achtergrondinformatie hebben, kunnen we het hebben over ons specifieke klantenscenario. Eén van onze internationale klanten heeft een locatie in Hongarije…
NAV Online Invoice System
“Navision?”, hoor ik u even denken… Geen zorgen, NAV is de naam van de Hongaarse belastingdienst: Nemzeti Adó- és Vámhivatal. Mijn Hongaars is vrij slecht, dus ik zal het maar houden op: Nationale Belasting en Douane Administratie. Deze NAV heeft bepaald dat vanaf 1 juli 2018 bedrijven in Hongarije verplicht zijn gegevens van hun afgegeven facturen aan te leveren aan het “Real-Time Invoice Reporting” (RTIR) platform van het online factureringssysteem.
Het betreft een online openbaarmaking van de gegevens van de facturen met een btw-bedrag van ten minste 100.000 HUF (wat op dit moment neerkomt op ongeveer 280 EUR). De belastingbetaler is verplicht de belastingdienst gegevens te verstrekken over facturen en gelijkaardige documenten die zijn uitgereikt voor de levering van goederen en diensten die door de belastingbetaler zijn geleverd. Daartoe heeft de nationale belastingdienst een elektronisch platform ter beschikking gesteld, het “NAV Online Invoice System”.
Real-Time Invoice Reporting setup in D365FSCM
Om de online facturatie werkend te krijgen in een Hongaarse rechtsentiteit in D365FSCM, moesten we ER-configuraties opzetten en de functionaliteit voor elektronisch berichtenverkeer voor RTIR configureren. De volgende taken moesten worden uitgevoerd:
- Importeren van de meest recente versies van de benodigde ER-configuraties (Invoices Communication Model, Electronic Messages framework model, RTIR-model mappings en RTIL-gerelateerde XML-formats) en instellen van applicatie-specifieke parameters.
- Stel de EM-functionaliteit in door een pakket gegevensentiteiten te importeren dat een voorgedefinieerde EM-configuratie bevat.
- Stel alle parameters in om de EM-functionaliteit gebruiksklaar te maken voor RTIR.
- Test het RTIR-proces door automatisch acties uit te voeren die in de verwerking zijn opgenomen, op basis van de status van berichten en berichtitems. Hiervoor konden wij gebruik maken van de beschikbare NAV-testwebsites en webservices.
We hebben een aantal uitdagingen moeten overwinnen om alles werkend te krijgen in D365FSCM. Het was een interessante kwestie van:
- Vallen en opstaan,
- Debuggen en analyseren van de technische foutinformatie in de XML van de responsberichten die van de webservice werden ontvangen,
- Het maken van een afgeleide versie van de “RTIR mapping”-configuratie om een paar bugs op te lossen,
- Aanpassen van applicatiespecifieke parameters van de “RTIR Invoice Data (HU)”-formatconfiguratie
- Fine-tunen van de financiële setup, enz.
Conclusie
Uiteindelijk waren we in staat om onze klant succesvol te helpen bij het naleven van de lokale elektronische belastingwetgeving. Het was een geweldige ervaring om te zien hoe D365FSCM met EM/ER een regelgevingsfunctie ondersteunt voor specifieke landen, om een technologische oplossing te implementeren die geautomatiseerde en elektronische communicatie met de belastingautoriteiten mogelijk maakt: Online Invoicing in de praktijk!
De voordelen van Kaya’s Business Monitor
Business Monitor is een add-on voor Dynamics 365 Finance & Operations (F&O). Het biedt een framework om integraties flexibel te implementeren en te configureren. Alle integraties kunnen herzien en beheerd worden vanuit één centrale workspace in F&O.
Beperkingen van het F&O datamanagement framework
In vrijwel alle Dynamics-implementaties is er behoefte aan integratie met andere applicaties, of het nu gaat om legacy-applicaties, purpose-built applicaties of externe API’s. Het datamanagement framework in F&O kan, samen met Azure Logic Apps, een groot deel van de meeste integratie-eisen vervullen.
Er zijn echter enkele integratiescenario’s waarbij de implementatie met de eerdergenoemde tools kan resulteren in een zeer complexe en kostbare Logic App orchestratie. Neem bijvoorbeeld een EDI bericht met one-to-many of many-to-many entiteitrelaties. Wanneer er veel F&O data-entiteiten bij betrokken zijn, kan de Logic App workflow zeer uitgebreid worden met veel acties. In dat geval nemen de operationele kosten van de integratie toe vanwege het pay-per-use prijsmodel van Logic App.
Wat betreft logging-mogelijkheden voor service-based berichten heeft het F&O datamanagement framework enkele beperkingen. Tegenwoordig zijn de meeste enterprise integrations service-to-service communicatie. Inkomende berichten die door een OData service worden ontvangen, worden niet gelogd in F&O. Indien een fout optreedt tijdens de verwerking van een inkomend bericht, wordt de fout teruggestuurd naar de gebruiker van de dienst en niet gelogd in F&O. Omdat inkomende en uitgaande service-based berichten niet worden gelogd, kunnen de berichten niet opnieuw worden verwerkt of gegenereerd vanuit F&O.
Business Monitor als aanvulling op F&O
Business Monitor voor F&O vult deze gaten op. Het biedt een framework om integraties flexibel te implementeren door inkomende berichten te verwerken met een F&O handler class in plaats van een Logic App workflow. De handler class biedt flexibiliteit doordat de ontwikkelaar bestaande data-entiteiten kan hergebruiken, custom code kan schrijven of een combinatie van beide kan implementeren. Alle inkomende en uitgaande berichten die in Business Monitor zijn geconfigureerd, kunnen worden herzien en beheerd vanuit één centrale workspace in F&O. Met de berichtengeschiedenis van Business Monitor kan een beheerder de inhoud van het bericht en de bijbehorende processing exceptions bekijken en kan hij berichten vanuit de logs opnieuw indienen. Onderstaande afbeeldingen laten zien hoe dit eruitziet tijdens het gebruik van het systeem.
Message history – grid view
Message history – view exceptions
Message history – view message
Uitgangspunten van het framework
- Inkomende/uitgaande berichtgegevens worden gelogd in custom F&O staging tabellen.
- Het bericht zelf wordt gelogd in een generieke F&O berichthistorietabel.
- Data wordt geïmporteerd in F&O door middel van data-entiteiten (OData) of custom service (REST endpoint).
- Data wordt geëxporteerd uit F&O door middel van business events en eventueel door data-entiteiten.
- Elk bericht is gedefinieerd als een interface in Business Monitor. Elke interface heeft een interface handler class die business logic bevat om de geassocieerde staging table data te verwerken/te creëren.
Belangrijkste kenmerken
- Ophalen en opslaan van berichten in Business Monitor staging table data-entiteiten met behulp van Logic App, of JSON-berichten rechtstreeks naar Business Monitor’s inkomende berichtenservice sturen (REST endpoint).
- Uitgebreide logging mogelijkheden.
- Bestaande data-entiteiten hergebruiken of custom code schrijven in interface handler classes.
- Synchrone & asynchrone berichtverwerking.
- Opnieuw indienen van berichten vanuit de logs.
Voordelen
- Eén service call naar Business Monitor’s inkomende berichtenservice (ingezet op F&O REST endpoint) functioneert beter dan meerdere OData calls naar F&O data-entiteiten.
- Een enkele F&O message handler class voor elk interface bericht, in tegenstelling tot complexe orchestrations/workflows om meerdere F&O data-entiteiten op te roepen vanuit een externe applicatie.
- Verbeterde stabiliteit en flexibiliteit met interface handler classes:
- Middleware laag handelt alleen berichttransport af; alle validaties en business logic worden binnen F&O uitgevoerd.
- Minimale inspanningen wat betreft ontwikkelen: hergebruik indien mogelijk bestaande data-entiteiten.
- Maximale flexibiliteit: combineer data-entiteiten met custom codefragmenten of schrijf volledig custom code.
Kortom, Business Monitor biedt u meer flexibiliteit bij het implementeren en configureren van integraties. Aangezien deze add-on is ontwikkeld door Kaya kunnen wij u advies geven over het gebruik van de oplossing. Als u geïnteresseerd bent, kunt u contact met ons opnemen.
Azure Event Grid: hoe je events kunt maken en verwerken in Azure Queue
Azure Event Grid is een service voor event-based apps, waarmee je events van elke bron naar elk endpoint kunt sturen. In deze blog geven we 5 stappen om events te creëren en te verwerken met behulp van een console-applicatie. We gaan twee console-applicaties maken: één om events te posten en één om event-berichten uit de queue op te halen. De afbeelding hieronder biedt inzicht in de flow waarmee we zullen werken.
1. Maak Azure Event Grid aan
Als u Event Grid nog niet eerder binnen uw Azure abonnement hebt gebruikt, moet u mogelijk de Event Grid resource provider registreren door de volgende stappen te volgen:
- Selecteer het abonnement dat u gebruikt voor Event Grid.
- In het menu aan de linkerkant, onder Settings, selecteert u Resource providers.
- Zoek Microsoft.EventGrid. Indien niet geregistreerd, kiest u Register.
2. Aanmaken Event Grid Topic
Het Event Grid Topic creëert een endpoint waar we events kunnen posten. We zullen dit endpoint nodig hebben om events te posten via de console-applicatie.
3. Event Subscription aanmaken
In deze stap zullen we een queue instellen om berichten te ontvangen op de queue.
Voordat u een subscription aanmaakt, moet u een storage queue aanmaken in uw storage-account.
4. De eerste console-applicatie
Klantgegevens worden naar het Event Grid Topic gestuurd en daar als een event geplaatst.
Maak een console-applicatie met de naam EventCreator. Dit is de plaats waar gebruikers events kunnen creëren en posten op Azure Event Grid Topic.
Installeer dit pakket: Microsoft.Azure.EventGrid.
Maak dan app-instellingen voor TopicAccessKey en TopicEndpoint.
Na het instellen van de Endpoint URL en Access key kunnen we events posten op de aangemaakte endpoints. Om events te posten moeten we EventGridClient aanmaken, dus hebben we het Event Grid pakket alvast geïnstalleerd dat zal helpen om events aan te maken.
EventGridClient client = new EventGridClient(topicCredentials);
De volgende reeks code is om events te creëren op de geconfigureerde Event Grid.
CreateEventsList is een normale, statische functie om een aantal events te creëren. In het volgende event creëert het nieuwe klanten:
Zodra je de applicatie start zal deze 10 nieuwe event-berichten in de queue plaatsen.
5. De tweede console-applicatie
Om berichten uit de queue op te halen stel je app-configuratie in om opslag te verbinden. <add key=”StorageConnectionString” value= “”>.
Installeer vervolgens het Azure.Storage.Queues pakket.
Lees de connectiestring uit de app-instellingen en creëer een queue-client met een correcte queue-naam. PeekMessages zal berichten uit de queue ophalen.
Hopelijk helpen de stappen in deze blog u bij het maken en verwerken van events. Succes!
Bron: https://docs.microsoft.com/en-us/azure/event-grid/overview