Redesign library APIs

[tomkerkhove]

Redesign library APIs to be more intuitive and consumer-friendly

[stijnmoreels]

Could there be some examples of how this functionality will be used? I mean, like practical stuff... Right now, the library got a single component where all the functionality is located but the functionality ranges from all different kinds of stuff.

In current projects, how would interactions with the Azure Logic Apps typically happen?
Is it an option to introduce an LogicApp object where the CRUD actions that are now located on this masive component would be moved? Or is the functionality currently presented in the component something that will be used across multiple Logic Apps?

[stijnmoreels]

Otherwise we could build something like in the EventGrid repo, where a builder creates a client where simple operations are located. In an application, these client(s) could be put in a dependency container and pulled from services.

[stijnmoreels]

And then, I would have to ask how the PollForLogicApps... are being used. In what context exactly.

[mbraekman]

This test-framework is currently being used to verify the complete run of an interface, in which multiple logic apps can be tied together in 2 ways:

• either logic app 1 directly triggers the next logic app, comparable to _logicManagementClient.WorkflowTriggers.RunAsync
• either the PubSub-component of the Invictus Framework is being used.

Using the first method we have a correlation-Id which can be used to retrieve the run-information of that second logic app.
Using the second method, we also have a correlation-id, which is being passed along as metadata on the service bus message, however we don't know whether this logic app will immediately get triggered or if it will take some time. This is where the polling-functionality comes in, to ensure the test-developers don't have to build the polling-logic themselves.

[mbraekman]

Some of the logic apps within an interface, might be calling an API. Since during these test-runs you either don't want to call the actual API, or want to simulate a specific response, the EnableStaticResultForActionAsync-function for instance, offers the possibility to set the required mocking-response for that test-case.
What this will do is update the logic app to include this mocking-response.

Another reason why the CRUD-operations are present would be to temporarily create a trigger-logic app to simulate a trigger which cannot be achieved from code - for instance, picking up a file from an on-prem file-server.
But it might also be that someone might decide to add in an additional step (Update) to a different logic app to simulate a failure.

This means potentially multiple logic apps can be created/modified/deleted during a single test-run.

[mbraekman]

How does a typical test-run look like:

• Initialize:
  • or set mocking
  • or create dummy trigger logic app
  • or update logic app for specific behavior
• Actual test:
  • retrieve url of trigger-logic app
  • trigger the logic app (or use the Invictus test framework to publish a message)
  • get run-details of the first logic app + verify actions
  • use the correlation-id or a tracked property to poll for the logic app run next in line
  • verify the expected behavior
  • ... check next logic app run ...
• CleanUp
  • or disable mocking
  • or remove dummy logic apps
  • or remove updates on logic apps

[stijnmoreels]

Ok, amazing explained, @mbraekman . Thanks a lot!