Category: DevOps

Thoughts about automated API Connection resource deployments as part of Logic App ARM templates

Posted on by Peter Geil

Recently I did re-evaluate the current possibilities when tasked with fully automated ARM template deployments of Logic Apps which contain API Connections. TL;DR; as of today there is still no sophisticated method for automating the authorization process of OAuth secured API connections. Microsoft still recommends the same custom PowerShell approach as back in 2018 when I first did evaluate this deployment aspect. Of course this should be understood as a general inspiration, rather than the ultimate solution. But in the year 2020 I would expect that there are already more sophisticated approaches, which ideally should have been integrated to Azure DevOps release pipelines, similar as the Azure Key Vault release tasks or the neat parameter mapping features of the Azure Resource Group Deployment task.

You might ask, why this is of relevance in the days of Service Principal access methods (aka App Users, AAD App Registrations asf.), Azure managed resource odentities or even simpler static API keys. Short answer: not all API Connections do support these advanced authentication mechanisms yet.

How to authorize OAuth connections (as of today)

Quick recap: exemplary OAuth 2.0 authentication flow (Source)

In essence I see three choices:

  1. implement some semi-automated OAuth login process using f.e. PowerShell which needs manual intervention for doing the actual “login” (example) → moderate initial effort; can be re-used
  2. implement automated login process which f.e. follows the common OAuth 2.0 authentication flow. Login credentials could for example be stored and retrieved from Azure Key Vault in order to avoid security leakage → rather complex and relatively high initial invest, but can be re-used
  3. just open the affected API Connection ressources after they have been deployed and manually authorize them → low effort

Keep in mind, that #1 and #2 also need to be integrated to the automated deployment process with, for example, Azure DevOps releases. For #1 this will impose additional complexity, since the OAuth login dialog must somehow be invoked on the user’s client machine in order for him to take action. And strictly speaking, #1 and #2 do contradict the philosophy of truely automated releases (CI/CD) since they involve manual intervention.

My comment

In the end, one needs to weigh out the costs/savings of following a strict philosophy (automation; CI/CD) vs. following a rather pragmatic approach, where both sides have the same goals: streamlining the whole release process and making it as efficient as possible. For me, following choice #2 would represent that most elegant solution, which will only amortize in the mid-/longterm and is best suited for very mature customer/project contexts, where this very specific optimization would imho pay off the most. While choice #3 is the most pragmatic and also cheapest (in many ways) way to accomplish the same goal.

Solution Importfehler – Entity {0} cannot be disabled for relevance search, because child entity new_someentity is enabled for relevance search

Posted on by Peter Geil

Neue Woche neues Spiel. Von einem Tag auf den anderen begann der Import einer Base-Solution plötzlich fehlzuschlagen und zwar aus einem mir bis dato unbekannten Fehlergrund:

Entity {0} cannot be disabled for relevance search, because child entity ActivityMimeAttachment is enabled for relevance search.

Fehlermeldung des ImportSolution jobs

Erfreulicherweise inkludiert die Fehlermeldung auch gleich eine vermeintliche Lösung und auch insgesamt klingt das Fehlerszenario für mich im Ansatz nachvollziehbar, wenn auch mit einem amüsant-irritierten Beigeschmack.  Denn an den Einstellungen der Relevance Search, welche Teil des System-Customizings ist (Solutioneditor -> Entitäten -> Button “Relevanzsuche konfigurieren” im Entitätssubgrid) wurde in den betroffenen System seit dem letzten Deployment nichts mehr verändert. Zudem ist die Relevance Search Konfiguration nicht Teil einer Solution, sodass diese ohnehin nicht durch einen Solutionimportant zwischen mehreren Systemen verteilt werden kann.

Daher vermute ich dahinter mal wieder einen von Microsofts “Nightly-Harakiri-Patches” für die darunterliegenden Power Plattform bzw. Datenbank, welches häufig mit kleinen heimtückischen Seiteneffekten daherkommt, die erst bemerkt werden wenn es irgendwo gekracht hat.

Lösung

Ein vergleichender Blick auf die Einstellungen der Relevance Search in den betroffenen Systemen, offenbart auch direkt die vermutete Ursache: im Quellsystem liegt eine völlig abweichende Relevance Search Einstellung vor: u.a. betroffen waren die Entities “Notiz” (annotation) und “Anlage” (activitymimeattachment). Nachdem ich für diese die Relevance Search deaktivierte, liefen die automatischen Deployments auch wieder erfolgreich durch.
Vergleich: Relevance Search Einstellungen in den verschiedenen Systemen

Kommentar

Ich würde erwarten, dass derartige Fehler bereits auf Platform-Ebene abgefangen werden, da weil die Child-Relationship der besagten Entität “Anlage” (activitymimeattachment) anhand der Metadaten bereits zum Zeitpunkt der Konfigurationsänderung validiert werden kann, ob es aufgrund nicht mehr auflösbarer Eltern-Kind-Beziehungen später zu einem ungültigen Konfigurations-Stand kommen wird. Beim entfernen einer Elternentität X, müsste die Konfigurations UI bzw. die Plattformlogik dafür sorgen dass vor dem Entfernen der Elternentität, zunächst alle abhängigen Child-Entitäten aus der Relevance Search entfernt werden müssen.