Current filter:
                                You should refresh the page.
                                Support Center
                                0
                                0

                                Hello Simon,

                                Thank you for contacting us. We need some additional time to research this issue. Please bear with us.

                                Thanks,
                                Dennis

                                0

                                Hello Simon,

                                Thank you for your patience.
                                We did not design XAF Workflow Versioning objects to work with .Net WCF Versioning classes, or to work with long running and send/receive activities.
                                In other words, you can use the WCF Routing Service to route client requests to different WorkflowServices. For more details about this approach, see http://stackoverflow.com/questions/2433670/wf4-workflow-versioning-using-workflowservicehost
                                Let us know in case of any further questions.

                                Thanks, Dan

                                0

                                I am relative new to Microsoft and Devexpress so please excuse my ignorance.

                                Are you saying that if we want to use long running workflows that work with send/receive messaging we would be better of to ditch the DX WF solution and go for the Microsoft solution?

                                0

                                Hello Simon,

                                Yes, to start a Workflow instance and communicate with it via Send/Receive activities, you can use the approach that is described at Creating a Long-running Workflow Service.
                                Alternatively, you can use another approach that is shown in the 'SuspendedInstanceManagement' and 'CorrelatedCalculator' demos. You can download them at Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) Samples for .NET Framework 4.
                                I hope you find this information helpful.

                                Thanks,
                                Dan

                                0

                                The examples that you send me escape me.

                                We want to use as much as possible from the DevExpress WF solution and don't want to build from scatch.

                                What do we need to change/update/delete to the DX WF solution to make it work with long running workflows with send/receive messaging?

                                Thanks.

                                0

                                Hello Simon,

                                Our WorkflowServer implementation is not designed to handle long running Workflows via Send/Receive activities. We believe that this scenario is easier to implement using built-in methods provided by Microsoft:

                                - You can implement this behavior in the way described in the A Developer's Introduction to Windows Workflow Foundation (WF) in .NET 4 article;
                                - You can deploy a resulting Workflow via IIS, as described in the How to: Host a Workflow Service in IIS and How to: Host a Workflow Service with Windows Server App Fabric articles;
                                - You can use the Azure platform to publish a Workflow, as described in the Running .NET4 Windows Workflows in Azure article.

                                When following any of the approaches described above, you can still utilize DX activities since all activities are installed in the Visual Studio toolbox. You can specify a corresponding connection string in the app.config file (ConfigurationManager.ConnectionStrings["ConnectionString"]) or directly via the ObjectSpaceTransactionScope activity' ConnectionString property.
                                In addition, you can use the DevExpress.Workflow.Store.WorkflowInstanceStore class to store running Workflow instances in the database as Xpo objects (the XpoWorkflowInstance class).

                                Previously, when you asked a similar question in Workflow: Run on IIS/AppFabric?, we suggested that you design workflows in VisualStudio with the help of DX activities and use MS technologies to deploy Workflows. Now, taking into account your questions and scenarios, I recommend that you consider native Microsoft approaches to design your application because DX WorkflowServer and WorkflowHost classes are not good choice in your situation.
                                I hope you find this information helpful.

                                Thanks,
                                Dan

                                0

                                Hi Dan,

                                We did not have any experience using Microsoft/DevExpress technology when we started a couple of months ago.

                                DevExpress did not have a WF solution at that time.

                                Our main objective is to have an end-user workflow designer so the workflows can be changed/created at runtime.
                                The workflows must be able to persist and resumed from the client.
                                For example a workflow can create a task for a person (and persist) and must resume if the person has completed the task (the client signals the workflow to resume).

                                We also do not want to store workflow definitions on disk (either web role or worker role).
                                We believe this will give you an headache if you deploy on a scalable hosted enviroment like for example Windows Azure.

                                We investigated the possibilities of using Microsoft Workflow Foundation 4 and Microsoft IIS/AppFabric to host our workflows.

                                Drawbacks:

                                No out-of-the-box end-user workflow designer.
                                We have to build our own designer using the rehostable WF components (designer, toolbox, property, tracking etc.).

                                Workflow definitions are not stored in the database but on disk.
                                We have to build something as described in:
                                How To Load WF4 Workflow Services from a Database with IIS/AppFabric
                                http://blogs.msdn.com/b/rjacobs/archive/2011/06/15/how-to-load-wf4-workflow-services-from-a-database-with-iis-appfabric.aspx
                                I guess it works but it doesn't integrate in AppFabric that well.

                                Azure AppFabric Composite Application WCF/WF is not available at the moment.
                                http://www.microsoft.com/windowsazure/appfabric/overview/
                                We want a solution that can run on-premise as well in a hosted environment without changes.

                                Then came DevExpress with the Workflow Module...

                                Basically it has everything that we need:

                                Out-of-the-box end-user workflow designer.
                                Including tracking information, DevExpress object interaction etc.

                                Workflow definitions that are stored in the database.

                                A Windows service that will work on-premise or in a hosted environment without changes.

                                If I understand correctly you state that the DX Workflow Server does not play well with the long running workflows with send/receive activities.

                                You also state that if we go for IIS/AppFabric we can use the DX activities and the DX WF instance store for WF instances.
                                I assume we can also use the DX WF end-user designer, and the DX WF definition table to store WF definitions.

                                Basically what we need to do is implement the Workflow Server ourselves.
                                But if we use the DX WF persistence store for WF instances and WF definitions, I guess this is not going to work with the IIS/AppFabric engine.
                                And if we are going to use the IIS/AppFabric persistence and monitoring store, than we cannot use the DX WF end-user designer.

                                We feel we are in a predicament.

                                My questions:

                                As you can understand, we really like to stick to the DX WF solution.

                                Are there any alternatives to long running workflows using send/receive messaging using the standard DX WF solution?
                                Keeping in mind what we would like to achieve.

                                Because long running workflows are part of most enterprise applications, why does DX not support this scenario?
                                Can you give us an idea of what we can and cannot be done with the DX WF solution.
                                So we can get an idea of the scope of the DX WF solution.

                                What can we do to have the long running workflow scenario supported in the DX Workflow Module by DevExpress?
                                Why does DevExpress have no desire to integrate this in the DX WF Module?
                                Is this a purely technical driven issue? Or related to support or other plans for the DX WF Module?
                                Long running workflows seems like a reasonable scenatio for enterprise applications.

                                Please help us understand.

                                Thanks.

                                Simon.

                                0

                                Hello,

                                Thank you for the feedback. I greatly appreciate it and I really want to find an appropriate solution for your scenario.

                                >If I understand correctly you state that the DX Workflow Server does not play well with the long running workflows with send/receive activities.
                                Yes, one of primary aspects of the DX Workflow Integration architecture is that a client application should not be aware of workflow interfaces or the URL address ( this information is required with Send/Receive activities).

                                >Are there any alternatives to long running workflows using send/receive messaging using the standard DX WF solution?
                                Yes, a message from a client application to a workflow instance could be formed as a change in the database.

                                For example, there is a workflow that is started for a new Task object. This workflow should send an email once a task is marked as completed. For this scenario, I recommend the following activities structure:

                                <While (isTaskCompleted)>
                                  <ObjectSpaceTransactionScope>
                                    <GetObject(targetObjectId) -> task />
                                    <Assign isTaskCompleted = (task.State == "Completed") />
                                  </ObjectSpaceTransactionScope>
                                  <Delay 00:10:00/>
                                </While>
                                <SendEmail/>

                                With the approach above there is no necessity to explicitly notify a workflow instance that an end user has completed the task.

                                Could you please clarify the following objectives:

                                >The workflows must be able to persist and resumed from the client.
                                Do you mean by "persist" that a workflow instance should be started when an end-user creates a new object in the client application?
                                Do you mean by "resumed" that a workflow instance should continue execution when an end-user changes an existing object (or creates a new one) in the client application?
                                It seems to be true, but I want to know it for sure. It seems that with the approach above you can implement this behavior.

                                >Can you give us an idea of what we can and cannot be done with the DX WF solution.
                                You should follow scenarios that we have demonstrated in the WorkflowDemo application and our blogs at http://community.devexpress.com/blogs/eaf . If you cannot find an appropriate scenario, most likely, the XAF Workflow module is not designed to support it. Contact our support team to find a suitable solution for your scenario. We will do our best to help you.

                                >What can we do to have the long running workflow scenario supported in the DX Workflow Module by DevExpress?
                                The XAF Workflow Module already supports long running workflow instances. It is not designed to work with the Send/Receive activities only. It seems that I previously misunderstood your question, my apologies. I hope now you find my reply more helpful.

                                Thanks,
                                Dan

                                0

                                Hi Dan,

                                I appreciate it.

                                >Yes, one of primary aspects of the DX Workflow Integration architecture is that a client application should not be aware of workflow interfaces or the URL address ( this information is required with Send/Receive activities).

                                Understood! But...

                                We looked at the out-of-the-box possibilities of the DX WF module and to us it seemed that having a delay/polling mechanism is something that will give us performance/scalability problems when running a *lot* of workflow instances.

                                So instead of having a couple of thousand workflow instances polling the database so see if they can resume, we decided that we would be better of explicitly signaling the workflow instance from the client to resume work.

                                What do you think?

                                Intro:

                                We develop a Warehouse Management System where goods are stored and for example moved from one place to another.
                                This is done by users that have a mobile application where "tasks" are presented like for example "Move product XYZ from location A to location B".

                                A typical scenario would be:

                                A workflow has a job/task that must be performed by some user.
                                The task can be for example "Move product XYZ from location A to location B".
                                The workflow creates a task record in the database with all the details necessary for the user to perform the task.
                                The workflow persists in the database and unloads from memory.
                                After that there is no workflow instance footprint on the workflow server.

                                The user is presented with a list of different tasks.
                                The user selects the "Move" task and physically moves product XYZ from location A to location B.
                                After the user completes the task, the workflow instance is signaled by the client to resume work (loads from the database and continues where it left of).
                                No delay/polling mechanism on the workflow server.

                                The workflow resumes and completes.

                                Regards,

                                Simon.

                                0

                                Hello Simon,

                                >performance/scalability problems when running a *lot* of workflow instances

                                I have tested this approach internally with our incoming questions (hundreds of new active workflow instances every day) and found that it doesn't require a lot of processor/memory resources and that the database server loading time is not increased noticeably.
                                The low memory usage is provided by the TimeToUnload and TimeToPersist options:

                                            server.CustomizeHost += delegate(object sender, CustomizeHostEventArgs args) {
                                                args.WorkflowIdleBehavior.TimeToPersist = TimeSpan.FromSeconds(2);
                                                args.WorkflowIdleBehavior.TimeToUnload = TimeSpan.FromSeconds(5);
                                            };

                                Low database server loading is provided by light queries: all requests to a database are performed by a key member (targetObjectId).
                                Our WorkflowService process uses about 100Mb of physical memory and about 1 hour a day.
                                Could you try this approach with your incoming tasks traffic and write me about the results?

                                Thanks,
                                Dan

                                0

                                Hi Dan,

                                We did some testing. See attachment for details.

                                “Create 1000 target objects” will create 1000 target objects.
                                Then the workflow host will create 1000 instances of “Sleep rand between 4 to 12 sec”.

                                We see quite a load on the host.
                                Which is normal of course, but in IMO it is unnecessary and something we can do without.

                                The WMS operations will in itself be very time critical (milliseconds for the WMS backend).
                                And we probably will have performance challenges without the additional WF host load.

                                Also when you look at for example Windows Azure deployment extra load will cost us money.

                                We would like to push for the send/receive scenario to be integrated and supported by DevExpress.
                                We are willing to be the test subject in this case.
                                What are the possibilities?

                                Regards,

                                Simon.

                                perfmon.zip
                                0

                                Hello Simon,

                                We will try to add support for this behavior.
                                Please track the Workflow - Provide the capability to use 'Receive' activities when designing workflows to create a new workflow instance (CanCreateInstance) or to continue an existing one (CorrelationHandle) ticket to automatically receive notifications.

                                Thanks,
                                Dan

                                0

                                Hi,

                                You mean DX WF module support for long running workflows with send/receive messaging right?

                                Because the referenced suggestion is only part of the solution.

                                Regards,

                                Simon.

                                0

                                Hello Simon,

                                I have changed the subject of the S37724 suggestion to 'Workflow - Provide the capability to use 'Receive' activities when designing workflows to create a new workflow instance (CanCreateInstance) or to continue an existing one'.
                                The EndPoints automatic creation is a technical task while we are trying to support a user scenario that is based on the 'Receive' activity.
                                Don't hesitate to write to us if we have misunderstood your needs.

                                Thanks,
                                Dan

                                0

                                Thanks.

                                When can we expect the solution?

                                0

                                Hello Simon,

                                We have already implemented a solution and I have prepared an intermediate DXP and XAF builds for you.

                                To download installation packages, use links provided below:

                                http://downloads.devexpress.com/Share/XAF/110718/eXpressAppFramework-11.1.5.11199.exe
                                http://downloads.devexpress.com/Share/XAF/110718/DXperience-11.1.5.11199.exe

                                P.S. Please note that we plan to publish an official v2011 vol 1 maintenance update this week.

                                Thanks,
                                Dan

                                0

                                That is good news!

                                Thanks a lot for this quick fix.

                                Much appreciated!

                                0

                                Is there a short list available of what has been changed?

                                Thanks.

                                0

                                Hello Simon,

                                This build includes all changes we have introduced in XAF at this moment. Their list is not available yet. We will publish it together with the official update (11.1.6).

                                Thanks,
                                Anatol

                                To start a chat you should create a support ticket


                                If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

                                FOLLOW US

                                DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, Silverlight, ASP.NET, WinForms, HTML5 or Windows 8, DevExpress tools help you build and deliver your best in the shortest time possible.

                                Copyright © 1998-2014 Developer Express Inc.
                                All trademarks or registered trademarks are property of their respective owners