Slow down SmartForms rules processing

  • 9 October 2014
  • 5 replies
  • 1 view

Badge +6

I have a rule that is dependent on an event happening outside of the form and the SmartForm literally processes the rule too quickly.  I need to slow it down.  About 50% of the time the rule works as it is, but I get an intermittent error because it is going too quickly.

 

Any ideas?


5 replies

Badge +10

Hello wkucardinal,

 

How is the event triggered?  If it is a server event, this may be helpful: http://help.k2.com/kb000272

Badge +7

Hello,

 

Is the rule applied on a control of some sort like a drop down list or anything? I know that it is possible to use certain Events or Rules to delay populating a Form/View with data until the user explicitly asks for that data.  You can use different Execution Types to slow it down, like "one after another" instead of "concurrently."

 

Is it too fast in that the rule tries to fire or fires before the outside event happens? Is it literally that the outside event happens and the rule fires immediately after but no action successfully happens? Something else?  

 

I'm not sure if it'd help get to the bottom of this, but what is the error you're receiving? We may be able to find a similar case that will help solve yours knowing this. 

 

Hope this is figured out. It's a very interesting case.

 

 

Badge +6

Basically, here is the full scenario.  It is a solution built solely on K2 SmartForms and SharePoint, and is driven by a K2 Designer-based workflow.  It is important that this remain the basis of the solution as it is intended to be a lightweight, disposable application, without any reliance on K2 Studio or custom code.  With that in mind:

 

I've built a SmartForm that forms the basis of a ticketing/help desk application.  On submission of the form, the ticket gets written to a SharePoint list with initial details regarding the ticket that have been collected from the form.  The user also has an option of attaching one file attachment when they submit the ticket.  On clicking of a submit button, rules fire to make this happen.

 

Problem 1: 

 

Action: User A opens a ticket with an attachment called "log.txt".

 

Result:  Attachment is uploaded to SharePoint library storing attachments successfully.

 

Action:  User B opens a new ticket with an attachment called "log.txt".

 

Result:  Rule errors out with a naming conflict error.  Log.txt already exists in the SharePoint library.

 

Resolution:  Create folders in the SharePoint library to store attachments for each individual ticket.  It is reasonable to ask users to not use the same file names on a single ticket.  Although the naming conflict can still occur, it is less likely to occur than if all attachments were stored in the root of a document library.

 

Now, I need a way to dynamically create a folder for each ticket's attachments.  I generate a ticket number as part of the form submission, so I can create a folder with the ticket number.

 

Problem 2:  You cannot create a SharePoint library folder using any SmartForms rules, nor can it be done with a SmartObject method execution.  The only method I have found to do this out of the box is using SPWI and a SharePoint-based workflow.

 

Resolution 2:  When the ticket information is stored to SharePoint (after the user clicks submit, but before the attachment is uploaded), have the creation of a new list item (the ticket details) trigger a SharePoint workflow whose sole job it is to create a new folder with the ticket number as the name in the attachments document library.

 

Problem 3:  There is additional overhead with resolution 2 that is timing based.  Although the folder is always created in 1 or 2 seconds, sometimes the SmartForms rules execute so quickly, they try to upload the attachment BEFORE the folder is created.  This generates an error and user is unsure what to do.

 

 

I ended up figuring out that if I added in enough rules after the list item creation rule, and the attachment upload rule, I could slow the form down just enough to not ever error, but it is far from what I would call a leak-proof solution.  At the end of the day, I have decided to just not allow users to include an attachment when they initially start a new ticket.  Once the ticket is started, they will be redirected to a new view of their ticket that will allow attachment upload.  This will allow enough time for the folder to be created by the SPWI workflow.

 

At the end of the day, if I could create a SP folder from a SmartObject method, this wouldn't be a problem.  But I do also think there should be a rule to sleep rule execution for a pre-determined number of seconds.  I have run into this issue before and I usually end up just coming up with a different way to do it that was not part of the original plan.

 

I hope this is enough detail!

 

Badge +10

Wkucardinal,

 

Yes, that is quite a bit of detail. I think I have a possible solution, although it may require a bit of redesign in where things are stored.

 

I'd reccomend using a smartbox smartobject to store the details of the ticket, and using sharepoint for the file attachments using a sharepoint library.  Storing the ticket details in a smartobject will yield a considerable performance increase, especially if this system needs to scale beyond 10 users.  As for attachments, you do want those in sharepoint, as you're going to have considerable performance impact by storing those inside K2 if someone decides to upload a 50MB attachment.  Sharepoint does a great job at that aspect, therefore I would reccomend using it for the file attachment portion.

 

Basically, your sharepoint library will contain a TicketID, attachment number, and the attached file.  Everything else should be able to be stored through a smartbox object.  You can then use a combination of forms and workflow in order to build the solution, pulling the attachments based on TicketID.

 

Hopefully that helps!

 

Mike

Badge +6

Mike -

 

What you describe is what I am already doing, except I am using a SharePoint list to store ticket information, not a smartbox.  I try to avoid the smartbox as much as possible because I don't really want that data in the K2 db.  Also, I want to report on it via SharePoint in addition to K2's interface, so it is a better solution.

 

However, what you suggested does not address my quandary, which is that I need to create a SharePoint folder for each ticket number that is generated in order to store attachments related to that ticket in a specific folder referencing the ticket.  I am only able to  create a doc library folder through a SPWI workflow, and because the ticket number is not allocated until the form is submitted, the smartforms rule tries to upload the attachment to a doc library folder that has not always had time to be created yet by the SPWI workflow.

 

My "workaround" was simply to not allow users to upload attachments on the initial form submission.  I was never able to figure out how to slow down the SmartForms rules processing enough for the SPWI workflow to create the doc library folder consistently.

 

 

Reply