Skip to content
This repository was archived by the owner on Nov 14, 2024. It is now read-only.

Feature - redesign library with first cycle of refactoring #27

Merged

Conversation

stijnmoreels
Copy link
Contributor

@stijnmoreels stijnmoreels commented May 25, 2020

Separate logic app "single instance" and "many instances" functionality

Functionality on a single logic app is placed in the LogicAppClient while the polling is moved to the LogicAppsProvider.

Introduce 'temporary' functionality

This makes sure the setup/teardown of logic app operations are more managed/controlled.

using (logicApp.TemporaryEnableStaticResult("<action-name>"))
{
    // On dispose: disable static result.
}

Building polling function

Reworked the different polling functions available in a more streamlined/fluent design.

Task<IEnumerable<LogicAppRun>> pollingTask = LogicAppsProvider
    .LocatedAt(ResourceGroup, LogicAppName, Authentication, Logger)
    .WithTrackedProperty(trackedPropertyName, trackedPropertyValue)
    .WithTimeout(timeout)
    .PollForLogicAppRunsAsync(numberOfRuns);

Relates to #3

@stijnmoreels
Copy link
Contributor Author

stijnmoreels commented May 25, 2020

First proposal, @mbraekman , for the redesign of the library.
All is just proposal, all can be changed 😉 .

Feel free to give some feedback so I can make this better + bigger changes we can place in separate issues of course instead of pushing to this PR.

@stijnmoreels stijnmoreels linked an issue May 26, 2020 that may be closed by this pull request
Copy link
Contributor

@mbraekman mbraekman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some minor questions or request to add some additional tests.
You're doing a good job!

Copy link
Contributor

@tomkerkhove tomkerkhove left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a great API from a consumer perspective, well done 🎉

I've added a bunch of comments and suggestions but mainly nitpicking or testing requirements.

Next to that, I think we can introduce a bunch of unit tests for:

  • Verifing our converter is working
  • Ensure parameter validation works for LogicAuthentication, LogicAppTriggerNotFoundException & LogicAppClient

@stijnmoreels stijnmoreels linked an issue Jun 11, 2020 that may be closed by this pull request
/// <param name="logicAppName">The name of the logic app resource running in Azure.</param>
/// <param name="resourceGroup">The resource group where the logic app is located.</param>
/// <param name="subscriptionId">The ID that identifies the subscription on Azure.</param>
public LogicAppException(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should always order from least to most specific meaning - subscription, resource group, logic app name, message

{
Guard.NotLessThanOrEqualTo(minimumNumberOfItems, 0, nameof(minimumNumberOfItems));

string amount = minimumNumberOfItems == 1 ? "any" : minimumNumberOfItems.ToString();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Frankly, this still feels off. Both our methods relying on this provide 1 so we'll always use any which is not correct if you ask me.

I'd say that, if you want all runs, you don't provide this property and poll for a given amount of time or so which uses another flow than pulling for one; no? They are different but yet use same exact approach/parameters.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that a problem, since there could be an continuously amount of runs? And we're never sure if we have all runs. I think that's the reason why this was in the initial design.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use a max timeout but if that's how it worked before then that's it 🤷‍♂️

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The polling-mechanisms should have a max timeout, so either it returns the given amount of runs or it returns what it found after the max interval expired.
But that should've implemented, so should be OK.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, then I guess I have to add two different approaches on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, @mbraekman , this is now changed to this two-system approach. Can you approve/reject on this new changes? Thanks.

/// Runs the current logic app resource by searching for triggers on the logic app.
/// </summary>
/// <exception cref="LogicAppTriggerNotFoundException">When no trigger can be found on the logic app.</exception>
public async Task RunAsync()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It starts a Logic App without you having to worry about the trigger name; that's what I think based on the implementation.

Is that correct @mbraekman ?

Guard.NotNullOrEmpty(triggerName, nameof(triggerName));

_logger.LogTrace("Run the workflow trigger of logic app '{LogicAppName}' in resource group '{ResourceGroup}'", _logicAppName, _resourceGroup);
await _logicManagementClient.WorkflowTriggers.RunAsync(_resourceGroup, _logicAppName, triggerName);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we should log that for sure :)

Sounds like a test going wrong, no? Can you help here @mbraekman ?

Copy link
Contributor

@tomkerkhove tomkerkhove left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lost track of all the feedback but think most of it is said so giving a 👍 once you think everything is processed @stijnmoreels

@stijnmoreels stijnmoreels merged commit f4f624b into invictus-integration:master Jun 15, 2020
@stijnmoreels stijnmoreels deleted the feature/redesign-library branch August 30, 2021 08:27
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Revisit logic app custom models Redesign library APIs
3 participants