Thanks Gareth, and I'm glad to hear that you've done this task with such success! that's one more argument indicating this is the right thing to do, taking into account the requirements of my apps.
Best regards. On Thu, Jan 6, 2011 at 2:46 AM, Gareth McCumskey <[email protected]>wrote: > That would have been my way-to-do-it-right-but-time-consuming idea for you. > We in fact have done that ourselves we have a full API system to assist > communications between multiple applications (some with code we have no > access to) and it works beautifully. Good luck with implementing your > solution :) > > > On Thu, Jan 6, 2011 at 2:00 AM, Gustavo Adrian < > [email protected]> wrote: > >> First of all, thanks a lot for your feedback on this matter Gareth. it's >> really very helpful. >> >> The notification via web services as you've described is almost exactly >> what I have in mind for my actual app. But with only one difference. I want >> to create a "middle" app between the rest of applications involved, acting >> like a mediator, and having a simple REST api. So, one app needs to send one >> notification, it sends it to the mediator. Any app that needs to "listen" to >> that "event", would need to ask to the mediator if it has a notification of >> the event in question. I could use another DB directly to save notifications >> without an app too, making every application to send and query for messages >> there, but it would be too restricted. If I want to add/change some logic, >> implement security beyond the privileges of the DB or whatever, I guess a >> mediator app is better.. >> >> This approach has the drawback that the apps interested on receiving >> notifications won't receive them inmediatly (it's not a big deal for now). >> It all depends on how often the cron job runs the task to query for new >> messages. But it has a lot of benefits too, including the most important for >> me: Every app asks to the mediator for events. So I could, for example, add >> another application to listen to notifications on that mediator if needed, >> without modifying anything on the app that sends the messages. >> >> And talking about the application transaction (or business transaction), I >> think that a workflow could do the job if I can mark a step as failed if it >> has an error, and retry later until it can be done. And your idea of sending >> a mail to an admin in case it fails n times it's a good idea. >> >> I was thinking on creating a bundle with the ezComponent Workflow for >> this, but I've never used it before. It seems to be quite good for this >> task. Do you have any experience with this component? >> >> >> >> Again, thanks a lot for your advices! >> >> >> >> >> On Wed, Jan 5, 2011 at 5:16 AM, Gareth McCumskey <[email protected]>wrote: >> >>> Perhaps your best bet for this kind of system is to create some kind of >>> web services API on the other applications (REST, SOAP, whatever floats your >>> boat). Then when you create an entity and need to notify these other apps >>> you can do so directly by targetting their web services API and notifying >>> them directly about that creation. >>> >>> This has multiple benefits. Firstly, you will definitively know if the >>> notification was sent and recieved correctly. In the case of using REST its >>> as simple as "I got a 200 status code from that app so everything went ok". >>> As far as your workflow is concerned there are multiple ways to do this. The >>> simplest off the top of my head is to add an additional flag field to the >>> table where these entities are created (call it notification_success for >>> example) and on creation of the entity, send the REST call. If the call was >>> successful then update the entity with a 1 in notification_success. If >>> however it was not, then update the entity with a 0. >>> >>> Now, to deal with the 0 notification_success entities, you can create a >>> very simple symfony task that can be run on cron (every 5 minutes, half an >>> hour, whatever) that essentially does a select on all notification_success = >>> 0 and then retries sending the notification. If successful, update that >>> entity with a 1 else move onto the next. >>> >>> What this means is that you will infinitely retry sending notification >>> for all entities created. You can even apply logic that if the notification >>> has not been able to be sent after x number of tries inform an admin or >>> something about a problem. >>> >>> >>> On Tue, Jan 4, 2011 at 7:35 PM, Gustavo Adrian < >>> [email protected]> wrote: >>> >>>> I mean a notification system for other apps that may have to react to >>>> the event descripted on the notification. If this notification never >>>> arrives, the other apps couldn't be react as they should on that event. Of >>>> course I can mark the step as failed and retry later. Of course I'm looking >>>> for an edge case but I want to be prepared for any case. I'm developing >>>> some >>>> sort of CRM that will then expanded to a business management (don't know if >>>> this is the term in english). So I'll need all kind of workflows and a good >>>> error handling if any step fails in the way. >>>> >>>> Anyway, in short, I need to use some kind of workflow to manage the >>>> steps require for the process and, if some of the steps fails, I can mark >>>> them asi "failed" and retry later to begin from that point, and finish the >>>> workflow. I see it viable. >>>> >>>> >>>> >>>> Thanks for your feedback! >>>> >>>> >>>> On Tue, Jan 4, 2011 at 9:20 AM, Gareth McCumskey >>>> <[email protected]>wrote: >>>> >>>>> I still question whether the notification event, by whatever mechanic >>>>> you decide, is really that critical for success. Do you really need to >>>>> base >>>>> the entire success of the transaction in part on the success of a courtesy >>>>> message? Is the message itself really that critical to the success of the >>>>> transaction? Bearing in mind that most of the apps I have developed that >>>>> has >>>>> some kind of notification system, the notifications are usually just a >>>>> courtesy to make a users life simpler and there are alternate means for a >>>>> user to see if a transaction was successful, such as a web page to see the >>>>> newly created entity. >>>>> >>>>> Perhaps reconsider the need to have an entire transactions >>>>> success/failure be dependant on a notification. >>>>> >>>>> >>>>> On Tue, Jan 4, 2011 at 1:52 PM, Gustavo Adrian < >>>>> [email protected]> wrote: >>>>> >>>>>> Thanks for your answer Gareth. >>>>>> >>>>>> I used an email send as a step just for simplicity. It's very true >>>>>> that email sending is very unreliable. I was really thinking in every >>>>>> case. >>>>>> Maybe register a message in a message service to notify other >>>>>> applications >>>>>> involved of the event ocurred? the only thing that came to mind is that >>>>>> if >>>>>> the step fails to do its job (in this case, if the message couldn't be >>>>>> send >>>>>> for whatever reason), I could put it on a queue and retry later. >>>>>> >>>>>> In the case of a workflow that I'll create in my app too, configured >>>>>> even by the user, if a step fails to execute for whatever reason, the >>>>>> step >>>>>> could be have a status of failed, and retry again later. Maybe >>>>>> every business transaction could be configured as a workflow if any other >>>>>> action is needed after the entity/entities are created/updated/deleted? >>>>>> that >>>>>> way at least I would manage all the situations on the same way, and I >>>>>> could >>>>>> handle the steps needed in every business transaction, handling a retry >>>>>> automatically in case of failure. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> On Tue, Jan 4, 2011 at 3:47 AM, Gareth McCumskey < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Email is not reliable. Its as simple as that. The reason I say this >>>>>>> however is that when you rely on systems outside of your control, such >>>>>>> as >>>>>>> mail servers because remember, the recipients mail server also needs to >>>>>>> be >>>>>>> fully functional, you need to bear in mind that reliability is very >>>>>>> likely. >>>>>>> >>>>>>> All you can do is decide is what is more important. If you create an >>>>>>> entity and the email doesn't get through to the recipient, do you really >>>>>>> need to roll back the creation of that entity? Is it that vital that the >>>>>>> email is sent that it should affect whether a record in a database >>>>>>> exists or >>>>>>> not? And if the target recipient is a human and not an automated system >>>>>>> checking mail box programmatically, there is additional reliability >>>>>>> issues. >>>>>>> What if the recipient is not in that day? Has a power failure? Or just >>>>>>> doesn't bother reading his/her mail? >>>>>>> >>>>>>> If the system reading the mail box is an automated program, then >>>>>>> there are far better ways to communicate between software systems than >>>>>>> using >>>>>>> the relatively unreliable method of email. >>>>>>> >>>>>>> TLDNR: It is very very difficult to verify that an email sent to a >>>>>>> specific recipient arrived (I would even lean to impossible). Find an >>>>>>> alternate way to inform people if its that critical. >>>>>>> >>>>>>> On Mon, Jan 3, 2011 at 3:41 PM, Gustavo Adrian < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I know is not a Symfony specific question but I was wondering how do >>>>>>>> you guys manage a situation like the following: >>>>>>>> >>>>>>>> . Create an entity and save it to the database >>>>>>>> . Save the log to a file or whatever resource the system has >>>>>>>> . Send an email to notify people involved with the entity that this >>>>>>>> item was added to the system >>>>>>>> >>>>>>>> >>>>>>>> Now, if the entity doesn't get saved on the DB because of an error, >>>>>>>> you can rollback the transaction and everything is good. But what >>>>>>>> about the >>>>>>>> case in that the email couldn't be send because, for example, of an >>>>>>>> error on >>>>>>>> the SMTP server? the DB transaction was already commited, but the email >>>>>>>> failed. This situation would need to put all three steps in some sort >>>>>>>> of >>>>>>>> application transaction boundary, so in case any of the three steps >>>>>>>> fails, >>>>>>>> you can rollback the entire app transaction. >>>>>>>> >>>>>>>> One "solution" would be to begin the DB transaction, execute the >>>>>>>> three steps, and commit the DB transaction at the end. So if any error >>>>>>>> occurs in one of the three steps, you do a rollback to the DB and >>>>>>>> that's it. >>>>>>>> The problem with this approach, as you may guess, is that if you have >>>>>>>> a very >>>>>>>> long steps chain, you'll have the tables / rows involved in the >>>>>>>> transaction >>>>>>>> locked in the meantime, or the data you use in your transaction could >>>>>>>> be >>>>>>>> changed by other user if the transaction hasn't the proper isolation >>>>>>>> type. >>>>>>>> Not a good choice, definitely. >>>>>>>> >>>>>>>> Another solution would be to handle this with a workflow "engine", >>>>>>>> registering each step in a workflow and, if one step fails, try to >>>>>>>> retry >>>>>>>> later. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> How do you guys handle this cases? a workflow is the only choice? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> -- >>>>>>>> If you want to report a vulnerability issue on symfony, please send >>>>>>>> it to security at symfony-project.com >>>>>>>> >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "symfony users" group. >>>>>>>> To post to this group, send email to [email protected] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [email protected]<symfony-users%[email protected]> >>>>>>>> For more options, visit this group at >>>>>>>> http://groups.google.com/group/symfony-users?hl=en >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Gareth McCumskey >>>>>>> http://garethmccumskey.blogspot.com >>>>>>> twitter: @garethmcc >>>>>>> >>>>>>> -- >>>>>>> If you want to report a vulnerability issue on symfony, please send >>>>>>> it to security at symfony-project.com >>>>>>> >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "symfony users" group. >>>>>>> To post to this group, send email to [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected]<symfony-users%[email protected]> >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/symfony-users?hl=en >>>>>>> >>>>>> >>>>>> -- >>>>>> If you want to report a vulnerability issue on symfony, please send it >>>>>> to security at symfony-project.com >>>>>> >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "symfony users" group. >>>>>> To post to this group, send email to [email protected] >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected]<symfony-users%[email protected]> >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/symfony-users?hl=en >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gareth McCumskey >>>>> http://garethmccumskey.blogspot.com >>>>> twitter: @garethmcc >>>>> >>>>> -- >>>>> If you want to report a vulnerability issue on symfony, please send it >>>>> to security at symfony-project.com >>>>> >>>>> You received this message because you are subscribed to the Google >>>>> Groups "symfony users" group. >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected]<symfony-users%[email protected]> >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/symfony-users?hl=en >>>>> >>>> >>>> -- >>>> If you want to report a vulnerability issue on symfony, please send it >>>> to security at symfony-project.com >>>> >>>> You received this message because you are subscribed to the Google >>>> Groups "symfony users" group. >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected]<symfony-users%[email protected]> >>>> For more options, visit this group at >>>> http://groups.google.com/group/symfony-users?hl=en >>>> >>> >>> >>> >>> -- >>> Gareth McCumskey >>> http://garethmccumskey.blogspot.com >>> twitter: @garethmcc >>> >>> -- >>> If you want to report a vulnerability issue on symfony, please send it to >>> security at symfony-project.com >>> >>> You received this message because you are subscribed to the Google >>> Groups "symfony users" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected]<symfony-users%[email protected]> >>> For more options, visit this group at >>> http://groups.google.com/group/symfony-users?hl=en >>> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony users" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected]<symfony-users%[email protected]> >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en >> > > > > -- > Gareth McCumskey > http://garethmccumskey.blogspot.com > twitter: @garethmcc > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-users%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
