Calling Execute Stored Procedure Smart Service asynchronously

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?

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.

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.