Whenever the user submits a workflow request from Enterprise portal clicking more than once, multiple instances are generated. Kindly suggest a way to avoid as it is misleading.
Thank you.
Have a look here
In the event this.WorkflowActionBar.EvaluatingCanSubmitToWorkflow you could via the EP's Business Connector session call a static method in X++ to check whether a workflow for your current process / document / whatever already exists and avoid submitting it again. How you determine that of course depends on your environment / process etc.
Related
I'm trying to find whether the Episerver Scheduled job (Episerver CMS 11) is triggered manually or automatically.
While on finding in Episerver documents I do see the 'ScheduledJobTrigger' and 'ScheduledJobLogItem' are related to this. But still, I am unable to find out how to call the service for implementation and get the expected value. Can anyone help me on this?
In code, the ScheduledJob will not have a user associated with it's context when fired automatically (either via API or scheduled firing), whereas a manual start will have user context associated to it.
If you are looking to identify if this was triggered manually, checking that user context may be what you are looking for.
I'm developing a workflow with GeneXus GXFlow.
It's a purchase request that needs multiple approval. I don't know how many, it depends by the type of products. The request is approved only when all the products are approved.
I think that the only way to do that is a process instance that generates multiple process instances of a child workflow.
Is it possibile? Where I can find an example?
Creating multiple process instances might be a solution but there is a more efficient way to do it with multi-instance tasks.
Check out the documentation for the Loop Type property to see how to configure it:
https://wiki.genexus.com/commwiki/servlet/wiki?11898,Loop+type+property
When I append a new subscription in ORION, it automatically evaluates the condition and it invoques the designed end-point for that. I want that the new subscription affects only entities appended later.
Is there any way to avoid it or I have to control this at end-point level?
Related to this, is there any batch option to create several subscriptions at same time for a initial load of the platform?
Orion Version: 1.2.0
Regarding initial notification:
No, it isn't.
We understand that for some uses cases this is not convenient. However, behaving in the opossite way ruins another uses cases which need to know the "inicial state" before starting getting notifications corresponding to actual changes. The best solution to make everybody happy is to make this configurable, so each client can chose what it prefers. This feature is currently in our roadmap (see this issue in github.com).
While this gets implemented in Orion, in your case maybe a possible workaround is just ignore the first received nofitication belonging to a subscription (you can identify the subscription to which one notification belongs by the subscriptionId field in the notification payload). All the following notifications beloning to that subscription will correspond to actual changes.
Regarding batch option to create several subscriptions
No, there isn't any operation like that.
EDIT: the posibility of avoiding initial notification has been finally implemented at Orion. Details are at this section of the documentation. It is now in the master branch (so if you use fiware/orion:latest docker you will get it) and will be include in next Orion version (2.2.0).
I'm designing a MVVM application that does not use WPF or Silverlight. It will simply present web pages in HTML5, styled with CSS3.
The domain is a perfect case for using WF because it involves a number of activities in a long-running process. Specifically, I am tracking the progress of interactions with a customer over a 30 day period and that involves filling out various forms at points along the way, getting approvals from a supervisor at certain times, and making certain that the designated order of activities is followed and is executed correctly.
Each activity will normally be represented by a form on a view designed to capture the desired information at that step. Stated differently, the view that a user sees will be determined by where she is in the workflow at that moment.
My research so far has turned up examples where the workflow is used to execute business logic in accordance with the flowchart that defines it.
In my situation, I need for a user to login then pick up where she left off in the workflow (for example, some new external event has occurred and she needs to fill out the form for that or move forward in the workflow to that step.)
And I need to support the case where the supervisor logs in and can basically be presented with activities that need approval at that time.
So... it seems to me that a WF solution might be appropriate, but maybe the way I want to use it is inverted - like the cart pulling the horse so to speak.
I'd appreciate any insight that anyone here can offer.
Thanks - Steve
I have designed an app similar to yours, actually based on WPF, but the screens shown by the application are actually driven by workflows.
I use a task-based approach. I have some custom activities that create user tasks on a DB. There are different type of tasks, one for every different form type that the application supports. When the workflow reaches one of these special activities, the task is saved to DB and the WF goes idle (bookmark).
Once the user submits the form, the wf is resumed up to the point where another user task is reached and so on.
Tasks can be assigned to different users along the way (final user, supervisor, ..) and they have a pending tasks list where they can resume previous wf instances, etc.
Then, to generate user views (HTML5 forms in your case) you have to read the pending task and translate that into the corresponding form.
Hope you find it useful
I want to write a workflow application that routes a link to a document. The routing is based upon machines not users because I don't know who will ever be at a given post. For example, I have a form. It is initially filled out in location A. I now want it to go to location B and have them fill out the rest. Finally, it goes to location C where a supervisor will approve it.
None of these locations has a known user. That is I don't know who it will be. I only know that whomever it is is authorized (they are assigned to the workstation and are approved to be there.)
Will Microsoft Windows Workflow do this or do I need to build my own workflow based on SQL Server, IP Addresses, and so forth?
Also, How would the user at a workstation be notified a document had been sent to their machine?
Thanks for any help.
I think if I was approaching this problem workflow would work to do it. It is a state machine you want that has three states:
A Start
B Completing
C Approving
However workflow needs to work in one central place (trust me on this, you only want to have one workflow run time running at once, otherwise the same bit of work can be done multiple times see our questions on MSDN forum). So a central server running the workflow is the answer.
How you present this to the users can be done in multiple ways. Dave suggested using an ASP.NET site to identify the machines that are doing the work, which is probably how I would do it. However you could also write a windows forms client that would do the same thing. This would require using something like SOAP / WCF to facilitate communication between client form applications and the central workflow service. This would have the advantage that you could use a system try icon to alert the user.
You might also want to look at human workflow engines, as they are designed to do things such as this (and more), I'm most familiar with PNMsoft's Sequence
You can design a generic "routing" workflow that will cause data to go to a workstation. The easiest way to do this would be to embed the workflow in an ASP.NET application. Each workstation should visit the application with a workstation ID in the querystring:
http://myapp/default.aspx?wid=01
When the form is filled out at workstation A, the workflow running in the web app can enter it into the "work bin" of the next workstation. Anyone sitting at the computer for which the form is destined will see it appear in their list of forms to review. You can use AJAX to make it slick and auto-updating.