Calling Execute Stored Procedure Smart Service asynchronously

Certified Associate Developer

I need to call a stored procedure that takes a lot to complete (around 6min) and it does not return anything. It could be called in a async way that it would not matter. 

Having said that, can I just use the timeout field to give it a short value (one second) being sure that in the DB, the SP will complete even if my Process model completes?

Cheers

  Discussion posts and replies are publicly visible

  • Hi. There a a few things here to consider:

    1. your main process model could call a sub-process model asynchronously so that all your sub-=process does is call your Stored Procedure. That would allow your main process to continue without having to wait
    2. do you really want to start the SP and not care about the outcome? There are various non-happy-path scenarios you may want to consider - can your SP even get started? (is the DB up and available?) Could the SP fail in some way? i.e. not achieve what you hoped it would? Does your app care either way? If not, who should care, how will the know and what should they do about it?
    3. 6 minutes is an aeon in computing processing terms - does it really take that long? Has your SP been optimized? Do the tables it references have appropriate indexes to make your SP as efficient as possible?
  • 0
    Certified Associate Developer
    in reply to Stewart Burchell

    Hi Stewart, thank you for the reply.

    Responding each point:
    1. It already is a very small Process Model with a daily trigger in the start node, the smart service, and the end node. So it's no use calling it from a sub process. 
    2. It doesn't even have outgoing variables attached. The outcome really is non important. What it does is just to update some dates in the DB and the response would not make sense in the context of the Process model. 
    3. Yes, it does take that long sometimes. It even shows up in the health check as it being taking way too long. You may be right, it may not be optimized and the people who did it could have a look at it, but in a "appian perspective" I think there should be a way to "bypass" this.

    Node: I guess we could ad a DB trigger for it and not bother with the Appian side of it, but I feel that in some cases this could be useful to know.

  • 0
    Certified Senior Developer

    Hi Joaor,

    I suggest you the following:

    1) If the SP needs less than 1 hour, call the SP in a subprocess in async way (please set timeout parameter and ask to increment it to the support team if it is needed) 

    Start Process Smart Service - Appian 25.4

    Execute Stored Procedure Smart Service - Appian 25.4

    2) If the SP takes more than 1 hour use DB event (no trigger) to trigger it in async way. Events Overview | Server | MariaDB Documentation

  • 0
    Certified Lead Developer

    Create a separate async process that calls the SP, then use a!startProcess() to fire-and-forget

  • 0
    Certified Associate Developer
    in reply to MauRap1993

    I'm exploring the DBMS_SCHEDULER options (the DB is ORACLE). It believe it will the the way we will go forward.

    What I'm still wondering is if a short (1 second) timeout would also serve my purpose given that I really don't care about how long it takes or it's result.

  • 0
    Certified Lead Developer

    Since nobody else mentioned it yet: is the 6 minute run-time actually causing you any issues / errors?  Do you have reason to believe it's actively preventing something necessary from happening? 

    I already see your feedback that it's already a short process and there are no parent processes depending on it, and that was going to be my only point of feedback too.  Without that, I wouldn't worry about it unless it's actually failing on you sometimes.

  • 0
    Certified Associate Developer
    in reply to Mike Schmitt

    Hi Mike,

    Its not preventing anything, you are right. The only downside is that it sometimes shows as a possible improvement in the Health Check, as it says it is taking too long. 
    That is the reason that I asked if I used the Timeout input Field with a short value, if it would have any downside. 

      

  • 0
    Certified Lead Developer
    in reply to joaor4842
    I asked if I used the Timeout input Field with a short value

    I think this would have effects you don't want, unfortunately.  As in, if anything it will cause the procedure to abort before it's actually done.  Though I haven't tested whether or not it actually would, or whether it would merely make the smart service proceed on while the procedure continues working in the back-end.  You'd need to test this yourself, I believe - also consider that even if it "works" the way you want, it might cause an in-Appian error / warning to be thrown.  Between the two options, honestly I'd take the health check warning (these are easy enough to flag as an extenuating circumstance, organizationally, and then ignore).