We are planning to deploy Netflix conductor war in PCF and then create a Conductor client in Java that will communicate with the server and load the json(tasks and workflow creation ) on start up
Can we create the JSONs and load them at client start-uo ? I have tried googling but unable to find sample Conductor Client that can create workflows etc
Any help in pointing to this direction would be helpful.
Thanks in advance
Clients are like listeners with capability of doing the work (workers) and reporting back the status of the task to the conductor. This listening ability comes after a task of specific type is already scheduled by the conductor. For all this to happen the task definitions and workflow definition (metadata) should be fed into the conductor followed by the workflow execution through the rest end-point.
Why do you want to load the workflow tasks and definitions in the startup? Looks like you are using in-memory mode for your POC. For the workflow definitions and tasks to load on startup, use an external dynomite and elasticsearch configured. So that you will not required to load these every time you restart your server.
Hope this helps.
Related
I have a web api that's running 24/7 on LAN(due to data security reasons, it's not connected to the internet). I have to call one method inside it each morning around 07:00. I've read that Timers are not reliable. I do not own the server so I don't have access to the Task Scheduler. How can I achieve this?
Do you think I should tell them that I have to install the software? Would they let me use the Task Scheduler? Is there any way to do this without the Task Scheduler?
There are a couple of options that you should look into.
Native .NET Core solution through IHostedService
Hangfire
Personally, I like that you can configure a dashboard and see what happened during the execution of your scheduled tasks.
As suggested by #Lei Yang in the comments, Quartz.NET
Hangfire is still adding in-memory support. Therefore, you're required to have a SQL Server to store all the information about the job (triggers, states, etc.).
This can have a huge impact in your decision. On the other hand, Quartz.NET does support in-memory store type.
We have a few Spring Boot services running in a GCP Kubernetes Engine which expose their HTTP(over gRpc) API to the clients.
One task is to import very large data files. The proposed way is to upload files to Google storage and trigger an asynchronous import by providing the file-path to the import location and return HTTP 202 in case the request was valid.
Next, we set the status of the import to pending within the persistence layer (spanner) and trigger an asynchronous parsing and batch ingestion process. In case the import was successful we set the status to completed.
The only way for a client to know if the import was successful is to come back and poll our API for the current status.
And there arises the question then.
There are several load-balanced pods of the same kind. If the importing service crashes (i mean crash, not exception handling), there is no straightforward way for us to finally set the status to aborted. The status will remain pending forever.
We would like to circumvent the use of an additional layer like hazelcast if possible. Also, we`d like to avoid having another service that communicates with one or other pods directly, observes the states and does some fancy callback stuff.
Can anyone give a hint of how to tackle that problem in a best practice manner?
Many thanks.
I have a process which I will be invoking manually for the first time in prod environment. Thing is, the process stops when the server is down or if the server is stopped. In this scenario, I will not be able to invoke the process manually everytime since it will be in production environment and not feasible also. So i need to know how can i invoke a process automatically once the server is up?
Heard that one way is to write a custom component to start the process using livecycle implementation class.
Please let me know how to go about it?
Any help regarding this is much appreciated!
Thanks
There are at least two ways you can do this.
First is the custom component route. You invoke the process on component life-cycle start to ensure that the invocation happens every time your component is deployed.
Second is the servlet route. You invoke the process on the initialisation of the servlet making sure that the server started.
The servlet implementation is a better fit for purpose, the only downside is, you need to package and deploy it separately as it won't be a part of the LCAs.
You can find the code samples on how to invoke LC processes using APIs on adobe docs. You can use Java API, WS API or Rest, whichever you are more comfortable with.
http://help.adobe.com/en_US/livecycle/9.0/programLC/help/index.htm
Team:
I need to invoke a WF activity (XAML) from a WF service (XAMLX) asynchronously. I am already referencing the Microsoft.Activities.Extensions framework and I'm running on the Platform Update 1 for the state machine -- so if the solution is already in one of those libraries I'm ready!
Now, I need to invoke that activity (XAML) asynchronously -- but it has an output parameter that needs to set a variable in the service (XAMLX). Can somebody please provide me a solution to this?
Thanks!
* UPDATE *
Now I can post pictures, * I think *, because I have enough reputation! Let me put a couple out here and try to better explain my problem. The first picture is the WF Service that has the two entry points for the workflow -- the second is the workflow itself.
This workflow is an orchestration mechanism that constantly restarts itself, and has some failover mechanisms (e.g. exit on error threshold and soft exit) so that we can manage our queue of durable transactions using WF!
Now, we had this workflow working great when it was all one WF Service because we could call the service, get a response back and send the value of that response back into another entry point in a trigger to issue a soft exit. However, a new requirement has arrisen asking us to make the workflow itself a WF activity in another project and have the Receive/Send-Reply sequences in the WF Service Application project.
However, we need to be able to startup this workflow and forget about it -- then let it know somehow that a soft exit is necessary later on down the road -- but since WF executes on a single thread this has become a bit challenging at best.
Strictly speaking in XAML activities Parallel and ParallelForEach are how you perform asynchrony.
The workflow scheduler only uses a single thread (much like UI) so any activity that is running will typically be running on the same thread, unless it implements AsyncCodeActivity, in which case you are simply handing back the scheduler thread to the runtime while waiting for a callback from whichever async code your AsyncCodeActivity implementation is calling.
Therefore are you sure this is what you want to achieve? Do you mean you want to run it after you have sent your initial response? In this case place your activity after the Send Reply.
Please provide more info if these suggestions don't answer your question./
Update:
The original requirement posed (separating implementation from the service Receive/Send activities) may actually be solved by hosting the target activity as a service. See the following link
http://blog.petegoo.com/index.php/2011/09/02/building-an-enterprise-workflow-system-with-wf4/
I am trying to construct a simple windows workflow to monitor a directory for inbound files and do some DB updates using Windows WF 4.0. Currently I am planning to build a 'WCF Workflow Service' and host it as a 'Windows service' running 24/7 (with a daily service shutdown and startup).
Further in the future I am planning to consume this service using an ASP.NET/WPF application to create a basic dashboard kind of stuff.
Considering the idea of directory polling for files with WF hosted on windows service, does it seems to be a good idea? What can be the cons of this?
Please advice if there are any drawbacks on this or can this achieved by better means?
I'm actually doing this, but it is a bit more complex than you think, and should be avoided if possible.
You should not be blocking from within an Activity; if it is expected to be a long running Activity that is waiting from input from the outside (FileSystemWatcher event, for instance), the workflow should idle itself and wait to be woken from the outside.
How I did this was I created a workflow extension that hosted the FileSystemWatcher. Once the Activity was ready to watch for a file, it created a bookmark and passed it to the extension.
The extension then started the FSW, holding onto the bookmark.
When a FSW event was fired, the extension resumed the bookmark, passing in an object that contained details about the event. The Activity did what was needed with the event, then re-scheduled itself.
Normally I wouldn't have done this, but I had some requirements that forced me to use WF4 to accomplish this goal. If I didn't have to use WF4, I would have just spun up the FSW within the service and consumed the events.
Unless you expect to have to be very flexible with your configuration detailing what you do with the FSW event, and expect this to change relatively often during deployment of the service, I'd skip WF4.