4 Replies Latest reply on Dec 2, 2014 2:20 PM by Miketedeschi

    Many Business Processes (1000's attributes) against Single Lifecycle with Dynamic Windows

    Apprentice
    AndrewWard Sep 18, 2014 7:18 AM

      I am just starting out on the road of creating Service Requests to handle many different business processes in self service on service desk 7.7.1.

       

      LANDesk created a generic service request process intended to handle all standard requests - currently there are over 100 business requirements in the pipeline with more to come.

       

      The suggested approach from LANDesk is to have a single window linked to the generic lifecycle and use a window calculation to create a dynamic window with the relevant attributes displayed and unused ones hidden.  Each business process could require 30 attributes which means that I am looking at over 3000 attributes on the window being controlled by a single window calculation.

       

      I am only working on a single business process at the moment till I figure out how to get this done. This process is for Change to Terms and Conditions of Employment which is sub divided into 7 categories

      • Change Grade or Job Title
      • Change Location
      • Change to Job Share
      • Change Working Hours or Weeks
      • Extend fixed term appointment
      • Make Fixed Term Appointment Permanent
      • Soulbury Only: SPA points

      The window has a number of common fields required to match and drive the lifecycle e.g. user details, managers for approval, request status. Each activity has its own group box with the relevant attributes within it. To help put into context I have included these screen dumps.

       

       

      • TCEDesignView.png the design console view displaying all attributes
      • CGTSelected.png a web view with the Change Required trigger field set to Change Grade or Job Title and so the entry fields for those attributes are displayed in the matching group box.

       

      There are a couple of minor issues readily apparent

      • window layout - the web grid has expanded the left hand column
      • descriptive label - each group box has a descriptive label which cannot be addressed and hidden dynamically so the group boxes are being kept visible

      Any suggestions on how to best overcome these would be welcome.

       

      The attached selectorcalc.txt shows the window calculation code being used. Basically I construct a string with all of the attributes and properties listed using placeholders for turning them on and off. For the category selected the placeholders for the relevant attributes are set so hidden=false and mandatory=true while the remaining fields are hidden=true and mandatory=false.

       

      I would welcome any comments/suggestions/alternatives on achieving the same result.

       

      My main issues with this, however, are scalability and performance because as mentioned there could well be over 3000 attributes on a single form. This would require an excessively large string to be constructed which I am sure will have significant performance impact or even break due to a size or memory constraint.

       

      My intial reaction is to have a separate window for each business process but this will mean cloning the lifecycle which will introduce extra management complexity if the lifecycle is ever amended - which is highly likely in the early days.

       

        • 1. Re: Many Business Processes (1000's attributes) against Single Lifecycle with Dynamic Windows
          ITSMMVPGroup
          dmshimself Sep 18, 2014 5:14 PM (in response to AndrewWard)

          My own thoughts would be to trial both a single window and multiples, but that is just my view not that of LD, I hasten to add and I'm sorry if you got that impression.  Maybe a compromise of sets of similar windows with similar processes?  By the way I've rarely found the OOTB request process is enough for must customers.  There are usually special activities needed for requests containing some entries in the service catalogue.  So even here there is a balance between the complexity of the single process (having an all in one) and maintaining several similar looking processes.

          • 2. Re: Many Business Processes (1000's attributes) against Single Lifecycle with Dynamic Windows
            aparker Employee
            aparker Sep 18, 2014 11:31 PM (in response to AndrewWard)

            Hi Andrew,

             

            There are a number of ways you could approach this, but as a very quick response to what you have described, there is one critical issue that you will need to consider and that is limitation of SQL Server itself. Whilst we do not restrict you in developing the system, there are certain things we do not have control over and one of those is how big a SQL server table can be. My initial thought would be multiple processes and not to create a monster, but you may well have to create collections to handle the amount of data that you seem to need to collect.

             

            Andy

            • 3. Re: Many Business Processes (1000's attributes) against Single Lifecycle with Dynamic Windows
              Apprentice
              Miketedeschi Dec 2, 2014 2:18 PM (in response to AndrewWard)

              old thread, but regardless....

               

              my concerns:

              1. hundreds of fields within window manager will get messy.  remember that it's possible to cause irreversible damage to a window in rare cases.  i have seen weird things happen to windows when i'm being impatient. (starting at bootcamp) if you do this, I would keep some copies of the windows before you mess with them.

               

              2. another thing to consider is that one giant process means all your eggs (users) are in one basket.  This sounds like a dream for alterations for repetition avoidance, but it can be an even worse nightmare.  should you need to take it offline (even for something tiny) you have to take down every process.  it also prevents you from selectively rolling out a new version of the process, maybe to pilot something new.  Personally, I would prefer to piss off 20% of users vs. 100% of them if possible.  If you make changes and there is a problem discovered a few days after launching it, it might effect everything.

               

              3. reverse engineering hundreds of attributes might be pretty challenging months or years down the road, even if you were the one who design it -- and it might be even harder for another user to pickup where you left off.  A clever naming convention will be even more critical for your own sanity reasons, and certainly for the next guy.  With that many fields, I would maybe put a prefix on groups of related attributes to make it more manageable within object manager. everywhere.

               

               

              my suggestion:

              design your monster process to be a master template, but build-in decisions that allow highly customized branches to only apply to certain groups of actual business processes.  This way, you could make 5 copies of the master when it's ready, and apply 5 different windows to each process clone.  to keep it organize, you could put letters on each process, and on each window title, and somewhere on each window.

               

              Process v1 = master version 1, the only process you alter, but it's not used in production.

              Process v1a = clone of process 1, cluster A (uses window A)

              Process v1b = clone of process 1, cluster B (uses window B)

              Process v1c = clone of process 1, cluster C (uses window C)

              Process v1d = clone of process 1, cluster D (uses window D)

               

              next time when you make changes, or add new processes:

               

              Process v2 = master version 2, the only process you alter, but it's not used in production.

              Process v2a = clone of process 2, cluster A (uses window A)

              Process v2b = clone of process 2, cluster B (uses window B)

              Process v2c = clone of process 2, cluster C (uses window C)

              Process v2d = clone of process 2, cluster D (uses window D)

              Process v2e = clone of process 2, cluster E (uses window E) for new stuff, but changes still made in master

               

              That being said, I have never attempted anything so large, but I am very curious how you are making out.

              Mike

              • 4. Re: Many Business Processes (1000's attributes) against Single Lifecycle with Dynamic Windows
                Apprentice
                Miketedeschi Dec 2, 2014 2:20 PM (in response to Miketedeschi)

                I also created something that allows managers to give raises to employees, and change locations, give promotions, etc.  however, I probably only made 100 fields total.  I am curious how 1000 is going.