| 2021-04-07 | The Azure Data Architecture Map | EN |
| 2021-03-18 | Azure SQL Import (bacpac) does not finish | EN |
| 2021-01-12 | Back to custom CMS | EN |
| 2021-01-12 | zurück zum Custom CMS | DE |
| 2020-09-14 | Back to Wordpress | EN |
| 2020-08-12 | Application Lifecycle Management (ALM) and Power Apps | EN |
| 2020-08-11 | Application Lifecycle Management (ALM) und Power Apps | DE |
| 2020-05-05 | virtuelle Maschinen in Azure - Regionen und Kosten | DE |
| 2020-04-24 | Weekly CW17-2020 | EN |
| 2020-04-17 | Weekly CW16-2020 | EN |
I've written about the maps of Stephane Eyskens before. I must admit that I did not follow up on the following publishing's by him. Today I just noticed that he added another map to his portfolio.
The Azure Data Architecture Map - Microsoft Tech Community
It is pretty neat that he simply put a link to all of his maps in his most recent post so that one has all information in one place.
Today I was facing the challenge that an import of a BACPAC file did not finish in a reasonable amount of time.
The process simply remained unchanged for about 4 hours in the state you can see in the above screenshot.
After investigating this further I found the money quote in the Microsoft documentation [1].
The Azure SQL Database Import/Export service provides a limited number of compute virtual machines (VMs) per region to process import and export operations. The compute VMs are hosted per region to make sure that the import or export avoids cross-region bandwidth delays and charges. If too many requests are made at the same time in the same region, significant delays can occur in processing the operations. The time that's required to complete requests can vary from a few seconds to many hours.
The documentation also states that an import will be cancelled if it is not processed within four days.
Unfortunately the Azure portal does not offer an option to cancel an import out of the box. For this you need to use the PowerShell (inside the portal). You can find a detailed description for this here.
To speed things up you can perform this import using your local SQL Server Management Studio (SSMS). For this simply refer to the necessary steps in [3] specifically section »Importing a data-tier application in SQL Server Management Studio«. Of course this is only an option if your internet connection is sufficient for the amount of data that needs to be moved. If not you can still deploy an Azure VM and run the import process from there.
As you might have noticed I haven't published anything since the last entry where I mentioned that I switched back to WordPress.
Being a technical person I really don't like the experience of putting content into WordPress. Meanwhile I've been trying to get around this by faciliating the wp cli which didn't work out very well for me.
Therefore I decided to get back on track to create a custom CMS. This time in Python. For storing content I followed an approach which I was inspired by Aaron Pericki.
Moreover I looked into IndieWeb and therefore I decided to split content into different types like notes, articles and bookmarks. Due to this the feed structure of this site will change a little bit. You can find all details for feeds here.
If nothing is changed in the Feed Reader, all content will show up in this default feed (/feed) in the future.
Wie vielleicht jemand bemerkt hat, habe ich seit dem letzten Eintrag, in dem ich erwähnte, dass ich zurück zu WordPress gewechselt habe, nichts mehr veröffentlicht.
Da ich ein technischer Mensch bin, mag ich den Weg, um Inhalte in WordPress einzupflegen, nicht wirklich. In der Zwischenzeit habe ich versucht, dies mit Hilfe des wp cli zu umgehen, was bei nicht sehr gut funktioniert hat.
Deshalb habe ich mich entschlossen, wieder den eines eigenen CMS zu gehen. Diesmal in Python. Für die Speicherung von Inhalten folge ich einem Ansatz, der von Aaron Pericki inspiriert wurde.
Außerdem schaute ich in IndieWeb und entschied mich daher, Inhalte in verschiedene Typen wie Notizen, Artikel und Lesezeichen aufzuteilen. Dadurch wird sich die Feed-Struktur dieser Seite ein wenig ändern. Alle Details zu den Feeds sind hier zu finden.
Wird im Feed Reader nichts geändert, tauchen in Zukunft alle Inhalte in diesem Standard-Feed (/feed) auf.
After I switched to Hugo as the generator for this page before some time ago, I often asked myself if a comment function could lead to a higher degree of interaction. Of course, this question is difficult or even impossible to answer afterwards. Anyway, the page is now run by WordPress again.
All URL patterns used so far should still work. If not, please leave a comment.
This article will explain how to apply Application Lifecycle Management (ALM) in Azure DevOps for Power Apps. It will be shown how to set up the required Azure DevOps environment. Furthermore, it will be described how source code/Power Apps can be versioned, quality assurance can be performed and subsequently artifacts delivered to the production environment.
The history of the article is longer. The first draft was already written by me in 2019. In the meantime I have worked on it again and again. What finally kept me from publishing it was, in my opinion, not yet "finished" tooling of the "Microsoft Power Platform Build Tools for Azure DevOps - Power Platform | Microsoft Docs". The originally available tooling (Azure DevOps Extension) is still available now but has been marked as "DEPRECATED" since the jump to version 0.3.7. Already since the jump from version 0.1.16 to version 0.3.6 the original tooling has been fundamentally revised/improved.
In version 0.1.16, the access credentials (user name/password) had to be stored in plain text to set up the connection. Since version 0.3.6 this authentication can finally be setup using Service Principals.
Figure: Authentication methods
The old (not recommended) method (yellow) is still available. So the transition to the new option (green) is seamless, even for users who have already used previous versions of BuildTools or have not yet set up Service Principals. When changing to or starting with the current version of the Build Tools, you should always be using Service Principals.
Two versions are available in the Visual Studio Marketplace:
1. Power Platform Build Tools - Visual Studio Marketplace
2. (DEPRECATED) PowerApps BuildTools - Visual Studio Marketplace
As described above, this extension [2] is now marked as "DEPRECATED", so only [1] should be used.
The tools currently available for Azure DevOps are basically a wrapper around the SolutionPackager for D365 Customer Engagement (CRM).
The final architecture, for the integration of Azure DevOps and Power Platform, will look like the following on an abstract level.
Figure: Architecture overview
Microsoft itself suggests two different approaches for ALM in conjunction with the Power Platform. [^1] In this article the first variant is described, where only the source code is versioned, but not the packed solutions. In the context of classical software development this is also the normal way, because usually only source code and not compiled binaries are versioned.
Dieser Artikel wird erklären, wie man Application Lifecycle Management (ALM) in Azure DevOps für Power Apps anwenden kann. Es wird gezeigt wie die benötigte Azure DevOps Umgebung eingerichtet wird. Weiterhin wird beschrieben, wie Quellcode/Power Apps versioniert werden kann/können, Qualitätssicherung durchgeführt und im Anschluss in die Produktionsumgebung ausgeliefert werden kann.
Die Entstehungsgeschichte des Artikels ist länger. Der erste Entwurf wurde von mir schon im Jahr 2019 geschrieben. In der Zwischenzeit habe ich immer wieder daran gearbeitet. Was mich letztendlich von der Veröffentlichung abgehalten hat, war das meiner Meinung nach noch nicht "fertige" Tooling der »Übersicht über Buildtools für Azure DevOps - Power Apps | Microsoft Docs«. Das ursprünglich verfügbare Tooling (Azure DevOps Extension) ist jetzt zwar immer noch verfügbar aber seit dem Sprung auf Version auf 0.3.7 als »DEPRECATED« gekennzeichnet worden. Schon seit dem Versionssprung von 0.1.16 zur Version 0.3.6 wurde das ursprüngliche Tooling grundlegend überarbeitet/verbessert.
In Version 0.1.16 mussten noch zum Einrichten der Verbindung die Zugangsdaten (Benutzername/Passwort) im Klartext hinterlegt werden. Seit der Version 0.3.6 kann diese Authentifizierung endlich mittels Service Principals abgebildet werden.
Abbildung: Authentifizierungsmethoden
Die alte (nicht zu empfehlende) Methode (gelb) steht weiter zur Verfügung. Somit ist der Übergang auf die neue Option (grün) nahtlos möglich, auch für Nutzer die bereits vorherige Versionen der BuildTools verwendet haben oder noch keine Service Principals eingerichtet haben. Beim Umstieg auf die oder Beginn mit der aktuellen Version der Build Tools sollte auf jeden Fall der Wechsel auf die Service Principals erfolgen.
Zwei Versionen sind im Visual Studio Marketplace verfügbar:
1. Power Platform Build Tools - Visual Studio Marketplace
2. (DEPRECATED) PowerApps BuildTools - Visual Studio Marketplace
Wie zuvor beschrieben ist diese Extension [2] mittlerweile als »DEPRECATED« gekennzeichnet, daher sollte nur noch [1] verwendet werden.
Die Werkzeuge, die aktuell für Azure DevOps verfügbar sind, sind grundlegend ein Wrapper um den SolutionPackager für D365 Customer Engagement (CRM).
Die finale Architektur, für die Integration von Azure DevOps und Power Plattform, wird auf abstrakter Ebene wie folgt aussehen.
Abbildung: Architektur Übersicht
Microsoft selbst schlägt zwei verschiedene Vorgehensweisen für ALM in Verbindung mit der Power Plattform vor. [^1] In dieser Anleitung wird die erste Variante beschrieben, bei der nur der Quellcode versioniert wird, aber nicht die gepackten Solutions. Im Kontext klassischer Softwareentwicklung ist dies auch der normale Weg, weil sonst auch nur Quellcode und nicht kompilierte Binaries versioniert werden.
Bei einem möglichen (Teil-)Umzug virtueller Maschinen aus dem eigenen Rechenzentrum (RZ) nach Azure, muss auf jeden Fall auch die Kostenseite betrachtet werden. Hierzu sollten im ersten Schritt die Kosten für den Betrieb der Maschinen im eigenen RZ (direkt [^direkt] und indirekt [^indirekt]) ermittelt werden, damit man diese dann den Kosten (direkt) in Azure gegenüberstellen kann. Bei dieser Gegenüberstellung kann man die in Azure anfallenden Kosten optimieren, in dem für den anfallenden Workload die jeweils passende virtuelle Maschine ausgewählt wird.
When you try to focus on one technology, such as Microsoft Azure, as I do, you often forget to think outside the box. Due to the current situation, Google has made all online training materials for the Google Cloud currently available for 30 days free of charge.
Google Cloud learning resources at no cost for 30 days | Google Cloud Blog
Really a good possibility to extend your own knowledge and to look beyond your own nose, if you have not had any contact with GCP before.
If you have had contact with databases as a developer, ask why things are the way they are and what needs to be considered to prevent problems. »Things I Wished More Developers Knew About Databases« is a longer article, but a really good one.
There are several ways to get started using Microsoft Graph. One possible good one is »A Lap around Microsoft Graph Toolkit in Day 1 - An Overview of Microsoft Graph Toolkit«.
Developers who are starting to get involved with Power Apps are often surprised that OOTB there are no popup dialogs in Power Apps. But not everyone needs to reinvent the wheel. Therefore you should use components that have already been developed by others. »Canvas Power App Modal Dialog (Popup) - Power Platform Community« shows one possible way.
Julie Lerman wrote a very detailed article about the Entity Framework Core 3.0 with »Entity Framework Core 3.0: A Foundation for the Future«. Very interesting to read why the Entity Framework team has laid the foundation for further innovations with this version.
Uncertain which asynchronous messaging solution in Azure is the right one for a specific requirement? Then you should read the documentation »Asynchronous messaging options in Azure« from Microsoft to get a good overview of all available options.
If you want to start running an ASP.NET Core application in a container then you will often have basic questions about how to start it. Greg Roe has published a two-part article that explains exactly that. * »Hosting and ASP.NET Core API in a Container Part 1 of 2 - Building the Container« * »Push to ASP.NET Core API Container to Azure Container Registry Part 2 of 2«
