I am looking for a way to change the steps in the saga, example: insert a step during the processing, preferablly during runtime
Is it possible to do using sagas?
Sagas (particularly those written using Automatonymous) were not designed to handle dynamic configuration at runtime. They are a codified way to create process monitors and workflows.
If you need to dynamically modify the steps of a workflow, you could use the Courier routing slip, which is built into MassTransit. It allows an activity in the workflow to revise the itinerary, adding or removing steps (activities) as needed.
Related
I have a small question. Do we have any option to stop/terminate the flow where ever we want in Mulesoft 4? Example: After executing transform message or after logger processor want to stop/terminate the flow based on our business requirement.
Two different ways to achieve that are described in the KB article https://help.mulesoft.com/s/article/How-To-Stop-Or-Start-Flows-In-Mule-4-x-Programmatically
Basically you need to get an instance of the Mule registry, the lookup the flow and stop or start it.
Yes, you can make use of groovy script or java class to start/stop mulesoft at runtime. Drag and drop the scripting component from the palette and choose groovy as your engine and use the script below.
flowName = registry.lookupByName('flowName').get();
if (flowName.isStarted())
flowName.stop()
else
flowName.start()
Need suggestion on which library to use for a large react native mobile app using redux ? redux-offline or react-native-offline ?
I need to regularly check connection status, render view depending on the connection status, add actions to queue when offline and run them when online, cancel actions if some contradiction is there, and persist/rehydrate data offline.
I am using redux-offline in my react-native project, it works just great. The feature that you are looking for all are presents like
It regularly checks for connection status
Add action to offline anytime (online \ offline)
Run the action as soon as device became online (moreover, you can decide the retry interval)
You can write your own discard method to drop any action based on your business requirement.
It uses redux-persist which automatically persist\rehydrate data. Also, you can provide your own store mechanism.
redux-offline is working just great for me, Sorry, I haven't used react-native-offline yet so can't provide you any benchmark.
I would suggest going for react-native-offline.
React-native-Offline provides :
Easier queue handling for actions based on a regex expression or a list of actions
Auto Triggering the online only actions , once the network is back.
Your Saga looks cleaner and readable, with both online/offline cases , on a maintenance perspective.
Redux-Offline provides:
It basically on separate online and offline actions
Each action and associated rollback needs to be handled
Both provides the redux-presist with connectors of your preference.
I have evaluated both, and for my use case I decided to go with react-native-offline. I liked its integration and ease of setup with redux-sagas, and it's offlineQueue was very convenient to have when you expect your users to conduct many operations offline.
Can you have automated regression/integration tests for Azure Logic Apps?
And if you can, how? ... especially in the context of CI/CD builds and deployments
... and if you can't, why not!!
There isn't any out-of-the-box tooling yet to provide automated testing of Azure Logic Apps. We have a few customers who have followed one of the following patterns. There is also this article that goes into detail on how to create a Logic App deployment template:
After deployment (using a release management tool like Visual Studio Release Management), a series of unit tests are run (writtin in something like C#) to test the Logic App.
Since a logic app could have any kind of trigger (on queue item, on HTTP request), the code usually performs the action and asserts the result.
A logic app in the resource group that can run a series of basic tests in a workflow. This one requires a bit more chewing on, but idea being you have a workflow that makes use of connectors or "calling nested apps" to perform basic validation tests (ensure connections are active, etc.)
It's something we have had discussions on from time-to-time, but would love to know if you have any thoughts on what types of tooling/configuration you'd want to configure for an app (remember that some apps "trigger" on something like a message in a queue or a file in FTP).
I would like to share one of the approach for LogicApp testing that my team has followed.
First level of validation is the ARM template deployment status (ProvisioningState) which should not have any errors.
After that we have developed test automation using the logic app sdk which does the following
Get auth token.
Execute a specific logic app trigger with a synthetic transaction.
Waits till the execution is completed.
Gets logic app & its action status (succeed, failed or skipped), validates it as per the expected scenario.
Gets the outputs from each action execution, validates them against an expected scenario.
Repeat above steps for all the various cases that logic app might go through.
Hook this all-in CI/CD :)
Deployed an LA, ran a synthetic transaction & validated the results.
Hope this helps.
I have a mule flow and I want to automate the execution of the application without http listener
I want the mule application execute without enter "localhost:8081/app"
is it a way to do this?
Screenshots of the flow
As I understood from your question, I can suggest the below steps
1) Add Composite source at the start of your flow.
2) Place the existing HTTP inbound endpoint into Composite source scope.
3) As an addition, add the quartz inbound endpoint into composite source scope and configure it at what time you want to run using cron expression.
This approach enables you option to trigger the flow using either HTTP URL or automated execution through quartz component using cron expression.
Please comment on this answer if you feel my understanding is wrong.
Do you simply want the app to run at scheduled intervals? If so, I think the Quartz connector would be you best choice.
Is this the scenario you are after?
I've been fighting and fighting for some time with a decent way to handle a workflow based on a series of asynchronous ASIHTTPRequests (I am using queues). So far it seems to have eluded me and I always end with a hideous mess of delegate calls and spaghetti code exploding all over my project.
It works as follows:
Download a list of items (1 single ASIHTTPRequest, added to a queue).
The items retrieved in step 1 need to be stored.
Each item, from 1 is then parsed, queuing a 1 ASIHTTPRequest per item, for it's sub-items.
Each of the requests from step 3 are processed and the sub-items stored.
I need to be able to update the UI with the progress %age and messages.
I'm unable for the life of me to figure out a clean/maintainable way of doing this.
I've looked at the following links:
Manage Multiple Asynchronous Requests in iOS with ASINetworkQueue
Sync-Async Pair Pattern Easy Concurrency on iOS
But either I'm missing something, or they don't seem to adequately describe what I'm trying to achieve.
Could I use blocks?
I see myself facing a quite similar issue as I got the exercise to work on a app using a set of async http and ftp handlers in a set of process and workflows.
I'm not aware about ASIHTTP API but I assume I did something similar.
I defined a so called RequestOperationQueue which can for example represent all request operations of a certain workflow. Also I defined several template operations for example FTPDownloadOperation. And here comes the clue. I implemented all these RequestOperations more or less accroding to the idea of http://www.dribin.org/dave/blog/archives/2009/05/05/concurrent_operations/. Instead of implementing the delegate logic in the operation itself I implemented sth like callback handlers specialized for the different protocols (http, ftp, rsync, etc) providing a status property for the certain request which can be handled by the operation via KVO.
The UI can be notified about the workflow for example by a delegate protocol for RequestOperationQueue. for example didReceiveCallbackForRQOperation:(RequestOperation) rqo.
From my point of view the coding of workflows including client-server operations gets quite handy with this approach.