Recently I had the challenge that we are doing an SAP upgrade and we needed to find out which Logic Apps would need to be retested and might be impacted by the upgrade to SAP.
In hindsight there are definitely a few things we will do which will make these kinds of impact assessments easier but we had an integration platform with over 500 Logic Apps developed over about 5+ years by multiple different projects and many different developers and some were when Logic Apps was pretty new and there wasnt a lot in the way of well recognised standards.
What I wanted to do was get an inventory of the Logic Apps which might integrate with SAP and while some are easier than others to identify I wanted to try and talk through this process as I thought it might be useful to others who would be likely to have similar impact assessments to perform.
Fortunately the Azure Resource Graph is really awesome and we can write kusto queries to help us perform a lot of what we need to do.
Looking for Logic Apps which use the SAP connector
The first step is easy, we want to identify Logic Apps which use the SAP connector. We can use the below query to do this.
resources
| where type == "microsoft.logic/workflows"
| where resourceGroup == "mikes-resource-group"
| where properties contains 'providers/Microsoft.Web/locations/westus2/managedApis/sap'Looking for Logic Apps which talk to SAP over HTTP via API Management
Next up we have a pattern where some of our Logic Apps talk to SAP via soap and odata. In most of these cases we will use Azure APIM as a proxy for these services so we can modify the query to use the paths for our API’s.
resources
| where type == "microsoft.logic/workflows"
| where resourceGroup == "mikes-resource-group"
| where properties contains 'integration/out/apps/sap'Looking for Logic Apps which use the SAP server name
We have some older Logic Apps which will talk to SAP directly using the HTTP connector to talk to SOAP or OData services. In these cases we can look for the server names. The below kusto query will identify if the sap server name is used as a parameter or hard coded from a deployment variable.
Ive also chosen to exclude the Logic App if it is also using the SAP connector as ill already have this Logic App from the earlier queries.
resources
| where type == "microsoft.logic/workflows"
| where resourceGroup == "mikes-resource-group"
| where properties contains '<server name>'
| where properties !contains 'providers/Microsoft.Web/locations/westus2/managedApis/sap'Looking for Logic Apps which use an SAP key vault secret
Next up we have some Logic Apps which might dynamically lookup the SAP server name from a configuration store at runtime and also lookup the secrets to talk to SAP over HTTP from Key Vault. In this case we can look for Logic Apps which use our Key Vault Secrets by name.
resources
| where type == "microsoft.logic/workflows"
| where resourceGroup == "mikes-resource-group"
| where properties contains 'SAP-Password'
| where properties !contains 'providers/Microsoft.Web/locations/westus2/managedApis/sap'Looking for Logic Apps which mention SAP in the tags
Next we are looking for Logic Apps which mention SAP in the tags. We have some Logic Apps which were developed for specific projects which might mention SAP as part of the project name.
resources
| where type == "microsoft.logic/workflows"
| where resourceGroup == "mikes-resource-group"
| where tags contains 'sap'
| where properties !contains 'providers/Microsoft.Web/locations/westus2/managedApis/sap'Looking for Logic Apps which mention SAP in the text
Finally we will to a fairly loose search of the entire Logic App text for any mentions of sap in the Logic App definition. We know its likely we might have some false positives here as sometimes the comments might reference SAP even though the specific Logic App might not talk to SAP. Also you might get cases where there is a value which might mention the letters “sap” as part of a string but it has nothing to do with SAP, but in this case we want to try to make sure we dont miss anything.
resources
| where type == "microsoft.logic/workflows"
| where resourceGroup == "mikes-resource-group"
| where properties contains 'sap'
| where properties !contains 'providers/Microsoft.Web/locations/westus2/managedApis/sap'What Next?
From the perspective of my impact assessment I not have a number of lists of Logic Apps. The ones from the earlier queries I can have high confidence they definitely integrate with SAP so I know these are in scope.
With the Logic Apps identified from the later queries I dont have high confidence they integrate with SAP but I do want to be sure we dont miss anything. I can use something like excel to remove the Logic Apps already identified from the earlier queries from the list of Logic Apps which matched based on either tags or text search. This gives me a list of potential matches which I can then go into the Azure Portal and review them and check if they do actually integrate with SAP or if they were a red herring.
In my case I was able to get a list of about 20 Logic Apps which I needed to review and it didnt take long to work out if they were integrating with SAP or not.
In less than a day I was able to workout from our 500+ Logic Apps in production we had 78 which integrate with SAP.
Lessons Learnt
The first lesson learnt here is that the opportunity to use tags is a good thing to do to help you manage some of this. Maybe in your Logic App you would have a tag called “integrates_with” which you add a CSV list of the applications your Logic App integrates with. You can then just query this out in your Kusto query. The one problem with this however is with Logic App Standard, I dont believe you can have workflow level tags and in the Resource Graph you cant query into whats inside the Logic App, you can only do this with Consumption and ISE. Note for Microsoft that would be a brilliant feature for architects.
The next lesson learnt is the importance of standards and consistent approaches. If all of our Logic Apps had used either the SAP connector or used APIM as a proxy for the HTTP calls to SAP then this would be much easier to identify all Logic Apps. We had some older approaches which used the HTTP connector and also used runtime lookups from a config store so its not that obvious without the run history that they call SAP.
The next lesson is the importance of an interface catalog. We do have one which Ill talk about in an upcoming post but not all of our older stuff is in it, so this exercise helped us back fill some of the Logic Apps which were missing from our catalog. We can use the catalog to help us identify the logical interfaces which are impacted by upcoming changes.
