| Author |
Message
|
| ata_nitjsr |
 Posted: Mon Sep 24, 2012 5:55 pm Post subject: Email Optimization needed |
 |
|
Acolyte
Joined: 08 Apr 2007
Posts: 56
|
Hi all
idea needed how to go for Email Optimization.
I have a email sending subflow which send email when a massage failed.
I need to optimize it some thing like should not send bulk msg of same error code. (eg : if webservice is not available then i am getting more than 1000 mail saying webservice not available )
Thanks
Atanu |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Sep 24, 2012 6:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
IMHO you need some kind of storage (shared variable, solidDB, Singleton) containing the error, the source of the error & when the error was last reported. That way you could determine if the error is really a duplicate (you don't want to not report a web service error just because a different web service has recently failed) and if it's time to email again (if the same error is still occuring n minutes after the 1st one, maybe it's time to ping the support people again).
Other, possibly better, solutions are undoubtably possible.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| NealM |
| Posted: Mon Sep 24, 2012 9:09 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
If one has lots of flows serving lots of purposes, there are going to be all sorts of levels of alerts, in some cases even one failure of a type could be a problem, in others it might be a trend across various flows of a type that needs reporting. I would think a variety of error queues with some error messages having expiries, and Omegamon or similar queue/flow monitoring product with alerts set at various queue depths would be a better approach if the purpose is to alert Admins or support.
And one avoids re-inventing the wheel... |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Sep 25, 2012 12:37 am Post subject: Re: Email Optimization needed |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
You could use a SHARED ROW and attach the error (number or text) there... probably also a timestamp and/or the number of times the error occured.
Then before sending the eMail off you can check/compare with these stored values.
So you declare a SHARED ROW in you flow. Then it will be available in your subflows (I think  ). And you can hand it over as a reference (or probably properly typed, so as a "IN(OUT) SHARED ROW") to the error-handling FUNCTIONs/PROCEDUREs.
... all done with very due dilligence... depending on how important (likely they are important) the error-eMails/Msgs are. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Sep 25, 2012 1:01 am Post subject: Re: Email Optimization needed |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| mqsiuser wrote: |
| or probably properly typed, so as a "IN(OUT) SHARED ROW" |
| mgk wrote: |
| REFERENCE is the correct datatype to use here as ROWs cannot be passed to or from an ESQL Procedure or Function |
Is this still valid, or did this change ? |
|
| Back to top |
|
|
| ata_nitjsr |
| Posted: Tue Sep 25, 2012 1:59 am Post subject: |
|
|
Acolyte
Joined: 08 Apr 2007
Posts: 56
|
shared variable concept the client is not ready to buy!!!
db we cant take if database is down then.....I dont know wht will happen.
Any Good idea? |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Sep 25, 2012 2:36 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| ata_nitjsr wrote: |
| shared variable concept the client is not ready to buy!!! |
There is no (other) choice. You can't say we do not want to do it 'like this and that' if there is NO OTHER 'that and that'.
SHARED ROW is dead easy ... what is the concern of your client ?
Though... on the error handling(-part) I would be cautious ... on what to do... keeping state (e.g. in a SHARED ROW)... probably no.
You could just scale your SMTP-Server (and eMail-InBox) or use a queue to buffer (the eMail-Msgs) and a subsequent flow which handles and just sends off only a few emails. If there are too many the flow then just stops/discards the rest. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 25, 2012 4:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ata_nitjsr wrote: |
| shared variable concept the client is not ready to buy!!! |
Why not? The concept of $0 capital cost & $0.50 development is too much for them?
| ata_nitjsr wrote: |
| Any Good idea? |
Yes. They've been listed & either you or your client don't like them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 25, 2012 4:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| Though... on the error handling(-part) I would be cautious ... on what to do... keeping state (e.g. in a SHARED ROW)... probably no. |
Why not? If something happens which is dramatic enough to clear out the shared variable, you probably want to send some more messages.
I agree that shared variables are not suitible for state in the sense of persisting a state through an orchestration or similar.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Sep 25, 2012 5:07 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| Vitor wrote: |
| Why not? If something happens which is dramatic enough to clear out the shared variable, you probably want to send some more messages. |
yes, carefully designed... avoid throwing exception or having errors in you error-handling-part
Good suggestion: If the shared row's content all of a sudden gets lost (who knows / flow restart), then make sure that (all) the eMails get send off.
It is something more to consider / to test (create a test case for). |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Sep 25, 2012 7:40 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| mqsiuser wrote: |
| SHARED ROW is dead easy |
The thing with shared row is: You declare it as a "SHARED ROW", but then you happily assign (tree-)data to it (as on the input/output-root or the environment). ROW stands out amongst the "SHARED ..." things that you (can) declare and it allows for more then just holding/storing (DB-)ROWs.
The (only) difference to the other trees is that the data is preserved and available on subsequent flow-invocations (until you stop/restart the flow)
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
|
|
