locked
design of a intranet application - with workfllow[wwf] or without WWF ? RRS feed

  • Question

  • User1693242203 posted

    hi,

    I am having a requirement to design a service desk mgmnt solution using plain asp.net withs ql db as database. how to do this,

    ie, since this service desk mgmnt consists of task assignment and response and closing the tickets raised during the process.

    I am confused, Should i implement the asp.net with Windows Workflow Foundation to achieve the  func.

    like employee raises a request and  it will go to a moderator and based on the category[ like desktop allocation, install s/w,remote dekstop access, admin access for the machine  etc etc] moderator will assign the task to his teammember[ called assignee : a role].

    assignee will resolve the issue and make changes to ticket's status  as resolved. if he needs  more info from user, he will make it as

    "user inputs needed" and assign the task back to the employee who raised the ticket.

    So,ultimately the ticket is resolved and task is assigned back to enduser or closure. so employee will click on the close button and  ticket's life cycle is completed.

    now my doubt/question is whether should i go with WWF to implement the solution 

    or

    simply i will create a task table and make changes to the table whenever theres  is  onclick of button  happens from the employee or  assignee or moderator and send  notifications wherever necessary.

    so that i can track the same also in a tickethistory table for future purpose.

    if i go with asp.net+WWF , how complex it is

     or what are the issues/problems i will be facing if i go with simple tasktable in my sql db and manage the ticket status.

     any help is highly appreciated.



    Tuesday, May 7, 2013 5:43 AM

Answers

  • User-488622176 posted

    You have a number of options:

    • Using WWF. You should define a process and define the ticket information structure. You can use the tasks to modify conditions so the ticket gets assigned to someone else
    • Using a service. This can be seen as a batch (windows service) that runs every X time, and determines the status of a ticket to change the assignment to someone else
    • Using an eventing system. The modification of a ticket implies a recalculation of who should receive the ticket next. This is done with every modification of the ticket.

    An extra thing you'll need to build is a "task list" per user (role) in the system. This contains all the tasks assigned to the user (role).

    All are possible, all have advantages and disadvantages.  If you have a non functional requirement implying the workflow will change regularely or should be modifiable easily, you should probably use WWF. However, if it has a drawback : for very high volumes and very simple processes it causes a lot of overhead. For simple processes without many modifications, the 3rd option is the simplest one to implement. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 7, 2013 8:56 AM

All replies

  • User-1618234021 posted

    I would n't recommend you to go for WWF unless you guys are using SharePoint. This can be done with ASP.NET and SQL Server.

    Tuesday, May 7, 2013 6:50 AM
  • User1693242203 posted

    hi,

     thnx for the reply. But how can we track the  lifecycle of my ticket?

    with each n every time status is getting changed and  notifications are sent cant we have a workflowid and correlationtoken   

    passing thru the ticket lifecycle.

    Tuesday, May 7, 2013 7:10 AM
  • User-488622176 posted

    You have a number of options:

    • Using WWF. You should define a process and define the ticket information structure. You can use the tasks to modify conditions so the ticket gets assigned to someone else
    • Using a service. This can be seen as a batch (windows service) that runs every X time, and determines the status of a ticket to change the assignment to someone else
    • Using an eventing system. The modification of a ticket implies a recalculation of who should receive the ticket next. This is done with every modification of the ticket.

    An extra thing you'll need to build is a "task list" per user (role) in the system. This contains all the tasks assigned to the user (role).

    All are possible, all have advantages and disadvantages.  If you have a non functional requirement implying the workflow will change regularely or should be modifiable easily, you should probably use WWF. However, if it has a drawback : for very high volumes and very simple processes it causes a lot of overhead. For simple processes without many modifications, the 3rd option is the simplest one to implement. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 7, 2013 8:56 AM
  • User1508394307 posted

    how can we track the  lifecycle of my ticket?

    You can add a history table where you can log all changes of each ticket

    history_log
    ----------------------------
    111  jsmith      created     05/07/13
    111  moderator   assigned    05/07/13
    111  teammember  completed   05/07/13 
    111  jsmith      closed      05/07/13 
    Tuesday, May 7, 2013 9:40 AM