Background Processes do not Advance

Good morning,

He has a client that has a large number of flows, and at the end of all the flows they have states that are triggered automatically and send the document for electronic signature. As the background process runs, it exits those documents and they are sent to be signed for a period of time that the flow has configured.

The problem happens that if there is any error in the document or sometimes without any known reason the background process gets stuck and for some error it got in the documents. I would like to know how I can see more information about the background processes, know what state it is stuck in or get a way to prevent them from sticking, since at the time of the problem if more than an hour passes, it can paste everything M- Files and causes problem for users.

Thanks to any help if anyone has a similiar process that can help me.

  • Is this a custom application that does this, or something like the AdobeSign / DocuSign integration?

    If it's a custom application then I assume you're using task queues/processors within the VAF.  If you are using the VAF Extensions then by default you should get a dashboard showing the task queue items and their current status.  You should be using job.Update to update the status periodically, and this status will be shown here.

    In addition you should use the VAF logging framework to log what is happening in your code.  You should output log messages at various verbosities.  You can then raise the logging level to make your logs contain more details, then drop it down again later when you've resolved the problem.

    You should also be using general exception trapping in your processors.

  • Almost all flows have 4 automatic state transitions at the end, where the document is renamed, converted to pdf and sent to the signing portal and the signed document returns. All this in those 4 states where only vbs are used to perform this operation. At the beginning of these four states is a time that causes them to run when the background process starts. but the background process is collapsing, I would like to know what options I can apply since there are 70 workflows that carry out this process.

  • I'm not sure I understand.

    What triggers the transition to the first state?  And it's then automatic state transitions between the four states?

    From M-Files's perspective if any of the scripting on any of those states fails then the transaction itself will fail, so it will appear to not move into the first state.  Is that what you're seeing?

  • So that users do not have to wait when sending the document, an automatic transition is made with the following vbs. After that it's pure simple automatic transitions that take you to the end. In one state it renames the document, in another it converts it into a pdf, in another it sends it to advanced electronic signature and returns.

    Const I_TIEMPO = 1837
    Dim dTiempo
    
    dTiempo = PropertyValues.SearchForProperty( I_TIEMPO ).TypedValue.GetValueAsTimeStamp().UtcToLocalTime().GetValue()
    
    'Err.Raise MFScriptCancel, dTiempo
    
    Dim iDelay : iDelay = 1
    
    Dim dGoAhead : dGoAhead = DateAdd("n",iDelay,dTiempo)
    'test time settings to verify the setup.
    'err.raise mfscriptcancel, "dCreated (UTC converted to local time):" & dTiempo & ", dGoAhead: " & dGoAhead &  ", now (local time):" & now
    if Now >= dGoAhead then
    			AllowStateTransition = True
    end if

  • And this never triggers?  The object never moves into the first of the states?

    Are there any errors in the Windows Event Log?

  • It does activate, but it only does so when m-files updates the object's workflow states, at which point it starts sending the files. The problem is that sometimes 120 documents accumulate and when the update starts and can't send trigger a document m-files it gets to the point where it gets stuck and doesn't allow to work, the update workflow object states it doesn't make progress when this happens and it can take up to over an hour for us to intervene. Only these errors appear, 2 or 3 of these errors but looking for the id are template documents as far as ican see

    M Files Online
    MLB_SGD 
    
    Error in the automatic state transition of the object "202-3308".
    Protect and commit operations in scripts must occur on matching pairs.
    
    StateChanger.cpp, 547, Automatic state transition of object "202-3308" failed. (0x800408A2)
    MCallInLoop.h, 521, Automatic state transition of object "202-3308" failed. (0x800408A2)
    StateChanger.cpp, 669, Automatic state transition of object "202-3308" failed. (0x800408A2)
    StateChanger.cpp, 669, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 25951, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 26081, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 9606, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 11069, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 25951, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 26081, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 9453, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 10175, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelper.cpp, 25627, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelperPrivate.cpp, 2967, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelperPrivate.cpp, 3184, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelperPrivate.cpp, 3606, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    RPCDocumentOperationsHelperPrivate.cpp, 4481, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    VaultScriptSessionTemplates.cpp, 275, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    VaultScriptSessionTemplates.cpp, 340, An error occurred while executing the script. ((Deactivate, StateAction: 202-3308-4)) (0x800408BB)
    VaultScriptSessionTemplates.cpp, 340, Check-in and commit operations in scripts must occur in matching pairs. (0x80040837)
    VaultScriptSessionTemplates.cpp, 531, Check-in and commit operations in scripts must occur in matching pairs. (0x80040837)
    VaultTrTrackerHelper.cpp, 643, Check-in and commit operations in scripts must occur on matching pairs. (0x80040837)
    VaultTrTrackerHelper.cpp, 1393, Check-in and commit operations in scripts must occur on matching pairs. (0x80040837)
    (M-Files 23.5.12628.4 2023-07-19T15:19:03.447Z)

  • Automatic state transitions are checked when the object is modified and then once per hour or so (it's changed in versions of M-Files over time, but I think once per hour is the current value).

    The specific error you see is often to do with a script which checks out an object but fails to check it in, perhaps because an unhandled exception occurs elsewhere.  Check that your VBScript code isn't using "On Error Resume Next".

  • And is there a different way to be able to trigger those transitions without depending on the update process of m-files?

  • You could use something like a VAF application with a task processor to periodically attempt to move them, but if the VBScript is failing for some reason then that won't help - you still need to understand why it's failing before you can plan a route forward.

    If it's some transient network issue stopping the objects being sent to the remote system, for example, then retrying periodically is probably a sensible approach.  If it's something inherently wrong with that specific object then it'll never fix itself, so retrying is not a sensible approach.

    As I said before: check your Windows Event Log, ensure that your VBScript isn't hiding exceptions using On Error Resume Next, and also make sure that there are no logic paths whereby an object may be checked out but never checked back in again.