New Bus Queues module

[sergiogp1]

What is this?
This is an app whose goal is to bring a way for developers to make more robust integrations between BC and external systems.

How is the app built?
This app is conceptually based on queues, so developers can enqueue an HTTP request and the bus queue will handle it. You can think of an Azure Service Bus simple "copy".

How does this app improve the integrations?
This could be a standard way to make integrations from BC, Developers wouldn't have to worry about coding retry logic and HTTP headers/HTTP body management is easier than using native data types.

Example:

BusQueue.Init('https://myurl.com', Enum::"Http Request Type"::POST);
BusQueue.AddHeader('Accept', 'text/plain'); //Header
BusQueue.AddHeader('Content-Type', 'text/plain'); //Content Header
BusQueue.SetBody('hello');
BusQueue.SetCategory('CUSTOMER');
BusQueue.Enqueue();

Things to mention:

• Code lies on Task Schedulder, and, as you may know, only 3 concurrent tasks are available per environment on SaaS. Programming this app in a synchronous way made no sense for me, that's why I use Task Scheduler. I saw no alternativate in BC. I ask myself if the limitation of 3 concurrent tasks can really imply a problem for some customers.
• BusQueue.AddCertificate is not implemented because TryFunction does not work to catch the error “the specified network password is not correct”. It only works with "asserterror" but I understand that is a bad practice.

Diagram flow:

[sergiogp1]

@microsoft-github-policy-service agree

[sergiogp1]

Should I maybe refactor to use the new AL Rest Client created by Arend-Jan Kauffmann?
Maybe this pull request can bring back again this [DRAFT] [New Module] Background Task Framework topic

[JesperSchulz]

Should I maybe refactor to use the new AL Rest Client created by Arend-Jan Kauffmann? Maybe this pull request can bring back again this [DRAFT] [New Module] Background Task Framework topic

I was going to suggest that 😊 But first I wanted to get some general feedback on your idea. Let's see if anyone provides some overall feedback on the usefulness of such module!

[duichwer]

How can we handle Authentication requests via this background Module securely?
And I it might be useful, if it implements the new rest client Module.
And we need good events as already proposed to process the response.
And are we already tracking which app inserted the request?

We currently have at least two apps that both implement background queue for web requests to transfer files.
We would need a way to easy filter on this table on our enqueued requests.

[sergiogp1]

How can we handle Authentication requests via this background Module securely?

Since it's for web requests, you would do BusQueue.AddHeader('Authorization', 'Beaerer ');. I'm not sure if I answer your question.

And I it might be useful, if it implements the new rest client Module.

Sure, I completely agree.

And we need good events as already proposed to process the response.

There is an event which is raised that allows to process the response:

ALAppExtensions/Modules/System/Bus Queue/src/Bus Queue Response/Public/BusQueueResponseRaiseEvent.Codeunit.al

Line 15 in 031b4a1

internal procedure OnAfterInsertBusQueueResponse(BusQueueResponse: Codeunit "Bus Queue Response")

And are we already tracking which app inserted the request?

Nope. I hadn't thought about that. There is not "trace" about which app inserted the request. That's a good point.

We currently have at least two apps that both implement background queue for web requests to transfer files. We would need a way to easy filter on this table on our enqueued requests.

I'm not sure I understand you on this point. Bus Queue table is Internal. Do you propose to make it non-editable but public to be consulted by other apps?

[duichwer]

How can we handle Authentication requests via this background Module securely?

Since it's for web requests, you would do BusQueue.AddHeader('Authorization', 'Beaerer ');. I'm not sure if I answer your question.

I was referring to something like OAuth were we need to request the Bearer Token directly before the processing via client secret/certificate and client id

I'm not sure I understand you on this point. Bus Queue table is Internal. Do you propose to make it non-editable but public to be consulted by other apps?

Well we should maybe at least have a good page where filter on specific values.
It would be helpful if the table is made public and most of the fields are marked internal.
Then we would only need some kind of Filter Functions to filter on the app ID or the category

[JesperSchulz]

@sergiogp1, could you port this PR from ALAppExtensions to BCApps? Given this is a PR for the System Application, it would be preferable to have it processed in the new repository. We're trying to get rid of the System Application in this repo. Also, having this PR on BCApps would give it more visibility. I could do that too, but then I would be listed as the creator of the PR, which isn't ideal...

[sergiogp1]

@JesperSchulz I will move it by my own. Thank you very for letting me know. I close this PR.