Workflow Soluiton

Hi,

I have been creating integration component for my incident workflow to get asset details and some custom dataclasses from CMDB to Processmanager.

I have used Resource components generator for NS 7. It seems to work fine if I just import few lines of data but when I try to import all asset data to be sorted out later it hangs and crashes. Is there some kind of limit of how much data can be imported from CMDB or how long is the timeout and can it be changed?

I don't know how else to get along with my workflow than getting all data for resource names at once to processmanager.

are you attempting to process the action in the debugger, or with a published project?

the debugger can sometimes only process so much data before it just gives up and is busted.  normally i just process a subset of data in the debugger to test the process, find any errors, and then publish and run the entire dataset via the published project.

Same error occures with a published project.

There is two log entries in the log viewer, when running the published project;

System.Threading.ThreadAbortException: Thread was being aborted.

and

Error starting/continuing dialog model execution System.Exception: Execution Engine Exception  ---> System.Threading.ThreadAbortException: Thread was being aborted.

I'm replying to this on behalf of JanneP, since he is referring to a workflow that is beeing created for me.

From the exceptions messages I infer that component you use is placed somewhere inside a workflow task or is placed between dialog forms. In such case this type of exceptions are usually thrown when your web request exceeds limits configured in IIS for ASP.NET applications. These limits are defined in web.config files (for application, site or global in machine.config) inside section like this:

<configuration>
        <system.web>
                <httpRuntime executionTimeout="110" maxRequestLength="4096" />
        </system.web>

        <system.webServer>
                <security>
                         <requestFiltering>
                                  <requestLimits maxAllowedContentLength="30000000" />
                         </requestFiltering>
               </security>
        </system.webServer>
</configuration>

According to MSDN the default values are: 110 seconds for executionTimeout, 4096 KB for maxRequestLength and 30000000 bytes for maxAllowedContentLength per request.

If you application throws an exception just about 2 minutes after web request it's a good track. I my opinion you should start with reconfiguring executionTimeout parameter for you application.

More details you can find here:
http://msdn.microsoft.com/en-us/library/e1f13641.aspx
http://msdn.microsoft.com/en-us/library/ms689462.aspx
http://forums.iis.net/t/1169846.aspx
http://weblogs.asp.net/jeffwids/archive/2009/09/24/from-iis6-maxrequestlength-to-iis7-maxallowedcontentlengthfile-specifying-maximum-file-upload-size.aspx

I changed the IIS timeout to 360 and now the exception occurs 6 minutes from the start. And before the change it was almost 2 minutes (110sec), as the default value for IIS is.

Now the problem is that to get the information we need from the CMDB (about 5000 rows) to the workflow, using this integration component, would require a timeout value of about 30 minutes...

Let's see if Symantec support finds a solution to this, otherwise we have to figure out an other way to get the information.

If you must wait so long for getting the data you shouldn't execute integration component inside Dialog Workflow or inside any workflow task based on web form dialogs where interaction is serviced by web requests.

There are several ways to bypass this problem:

1) Gather the data befor creating the task. The problem is the data won't be valid if task will be executed much later.

2) Create a pair of tasks: first for initiating data acquisition, second for processing the gathered data.

If you really need execute this component inside workflow task try to implement data acquisition as asynchonuous event and prepare a dialog form to wait for accomplishment of this event (autorefresh or something similar). However waiting for such a long time involves further problems like browser session timeout etc.