Is running LogicApps as `dotnet-isolated` a supported feature?

Question

Is running LogicApps as `dotnet-isolated` a supported feature?

Alexander Clare 0

transferred from this github-discussion

We´re currently developing some line-of-business (LOB) custom-connectors in order to be able to automate various tasks in our business. One thing we didn´t find anywhere documented / sampled is a way to "hook" into a workflows "lifecycle"-events, such as started, ended (or failed, maybe).

As there may be other things that´d be good to have finer grained control over, I started to try to host LogicApps (Standard) in a dotnet-isolated-mode, following these instructions here. Current hope is that this way we could levereage some middleware (or similar) to achieve the initial goal, as well as having complete control over the apps start-process, etc. seems like a nice benefit, also.

Sadly, I´m facing various issues when trying to get this running. I´ve got the feeling that I´d "just" need to reflect the same startup-configuration which azure functions core tools does in order to get LogicApps (Standard) in dotnet-mode up and running, but currently am missing the needed pieces / directions.

So:

Is dotnet-isolated a supported mode to host LogicApps (Standard) ? If so, are there any directions on how to configure the necessary services, etc. in program.cs?
Is there maybe another way to "hook" into described "lifecycle"-events?

Alexander Clare 0 Reputation points

2023-09-06T05:40:11.94+00:00

What does it need for someone to answer this question? Over at Github it is stated to post questions here. But what is the point of that when nobody cares at all?

1 answer

Your answer

Alexander Clare 0 Reputation points

2023-09-06T05:40:11.94+00:00

What does it need for someone to answer this question? Over at Github it is stated to post questions here. But what is the point of that when nobody cares at all?

Answer 1

Anonymous

Hey @Anonymous firstly we apologise this was missed

please do bump with a comment after a couple of working days if you don't receive a comment or answer. There is a responsive community for this tag (and other PaaS tags) working to ensure questions get answered. However in this case we could have done better.

To your question.

Yes it's supported for Logic Apps Standard , but it doesnt work in the way you may have expected , it's supported to enable a subset of features.
See Kent Weare's comment from this blog https://techcommunity.microsoft.com/t5/azure-integration-services-blog/net-framework-assembly-support-added-to-azure-logic-apps/ba-p/3669120
Comment:
*"When the FUNCTIONS_WORKER_RUNTIME is changed to dotnet-isolated, it is only used for features that need it like XSLT + .NET, new Data Mapper and upcoming .NET custom code feature. For features that don't use these components, they will be executed in node like the Inline Code action you specified. So you can think of it as additive as opposed to a replacement. "
*
If you need a feature that requires it you can change the setting in the config as described in the blog. No further steps should be required.

Anonymous

2023-09-06T12:08:26.0833333+00:00

For the original part of the question "One thing we didn´t find anywhere documented / sampled is a way to "hook" into a workflows "lifecycle"-events, such as started, ended (or failed, maybe)."

Can you expand more with an example, what is the custom connector doing, what are the requirements that would lead you to want to hook from workflow lifecycle events
Alexander Clare 0 Reputation points

2023-10-13T11:17:37.45+00:00

hey, nice this finally got a followup ;).

I´ll read through the linked article and may come back here, if there´s still anything unclear.

For my original question:

I ´d like to hook into this kind of lifecycle-events in order to add additional tracing-capabilities, which then may be incorporated in other applications.
But maybe this is some kind of XY-Problem, let me try to explain what I´m up for:

As stated, we´re implementing custom-connectors to assist in automating certain business-processes. During this, we also expect to create workflows which use these connectors. For such workflows, it would be nice to have some kind of added tracability.

Let´s say I have a workflow which gets invoked whenever "a new invoice has been created".
I´d love to have something at hand that would let me track which workflow picked up this invoice and processed it, w/o the need for the workflow to specify some kind of action.

But those are very early ideas and may not fit well into this. But it would be good know if there are extension-points for such kind of things.
Anonymous

2023-10-18T09:59:15.2566667+00:00

Hi @Anonymous
For completeness: There's a custom tracking capability in Logic Apps and App Insights can also be used to generate trace events (to the backing log analytics store) right now if you add app insights you really need to manually specify the v2 agent.

For info on how the above tie together see here https://techcommunity.microsoft.com/t5/azure-integration-services-blog/application-insights-enhancements-for-azure-logic-apps-standard/ba-p/3758909

However - APM App performance monitoring isn't reliable enough to drive business events - it's best-efforts

Back to the question: If we look at the suite of Azure services then event grid events would be the way to do this imho but there isnt that support right now

if you look very carefully at the underlying storage account for your logic app you'll notice that the storage is both used for state but it's also used for "events" , for example stateful workflow actions are invoked in an async / event driven way - we mention that in the following post (apologies because this one is a looong read) https://techcommunity.microsoft.com/t5/azure-integration-services-blog/logic-apps-standard-hosting-amp-performance-tips/ba-p/3956971

However, I dont think you could build on that yourself today - although it's close to what you're looking for

In the interim I think a notification through either event hub or event grid would work fine though - yes it's not "architecturally" as "pure" as the event is through the workflow - as opposed to being a side effect of the work flow ---- but it would work fine and it's a very common thing to do

(You can do similar with API Management which has a policy specifically for issuing events that represent things of business interest https://learn.microsoft.com/en-us/azure/api-management/log-to-eventhub-policy
Alexander Clare 0 Reputation points

2023-10-20T06:26:47.5133333+00:00

Ok, first of all, thx for pointing my nose on those nitty-gritty details.

Reading those blogs I come to the conclusion that the way I thought of to tackle this kind of "problem" is really not a good idea, especially if I take scaling into account.

So I guess the engineers which designed this whole stuff made rather good decisions by making it really hard to do what I was up to, as this would probably have led to major issues ( at least when scaled out).

I think with this having more clear, we probably need to think about either providing some "explicit" connectors or maybe leverage some implicit side-effect in already existing ones.

So to my original question (if running LogicApps as "dotnet-isolated" is supported): I think this should be answered as NO - at least relative to the underlying question, which I originally was up to, which is to f.e. having complete startup under control to be able to add e.g. a Middleware, which might magically do things. Doing this might have included spinning out some "shared" services (as scoped), which I learned would probably work for "stateless", but would introduce serious problems when scaling out "stateful"-flows.

So again, good choices of the engineering-team to make such relatively bad things really hard to do!

Share via

Is running LogicApps as `dotnet-isolated` a supported feature?

1 answer

Your answer