Send SMTP Email on Field change, form will not update

jversusjjversusj Member Posts: 489
I searched the forum and went through many threads, but was unable to find anything similar to the issue I am facing. We are running 3.7B codebase.

We have a custom table. There is an option field named 'Phase' on this table. Every time this field is changed (rec <> xrec), we want to send an email to a static email address using the SMTP codeunit (400).

I pass the record and the prior value as parameters into a function that calls the SMTP functions to CreateMessage, Append Body, and ultimately Send the email. The body uses Text constants and STRSUBSTNO to output record specific values in the email.

All of the above code works, when I change the value of the field, I promptly receive the expected email. The problem however is that the NAV GUI is not updating the value of the field. If I manually refresh my screen (Ctrl+Alt+F5), the updated value is visible. If I comment out the actual work being done in my function, NAV responds as expected (instant update of the field value).

Interestingly, this happens when viewing the record using a custom form AND if I view the table directly via Object Designer. I have tried adding MODIFY(TRUE), COMMIT (before and after email send), attempted CurrForm.UPDATE(TRUE&FALSE) on the form (before I noticed it in the table as well), etc., and so far nothing works.

I have also tried calling the code from the table (OnValidate and OnModify), from the form (OnValidate), with the SMTP function in the table versus in a codeunit - all of these lead to the same result.

It seems to have something to do with calling this SMTP CU. Any ideas? I have to think I am overlooking something simple, but it escapes me.

edit: looks like this CU was brought in from v5.00, not a part of standard 3.7b

edit 2: Ok - more experimenting - if i key an option value into the field, it works as expected. If I use the option Drop-down, the above scenario plays out with the form not updating. The difference, keying into the field actaully triggers OnAfterValidate, while selecting the value from the Drop Down does not appear to call it.
kind of fell into this...

Comments

  • ta5ta5 Member Posts: 1,164
    Hi
    I had a lot problems with smtp component of nav. Especially in NAS and in combination with timer events. After all I used a third party component (jMail for example) and the problems have gone.
    It looks imo like nav smtp component has a special behavior leading to unexpected changes in focus or thread or something like this.

    If you want to use jMail you can copy email codeunit to another id and change the new codeunit so it matches with jMail methods, quite similar to the nav smtp component. For testing you can use the demo license.

    Hope this helps
    Thomas
  • jversusjjversusj Member Posts: 489
    I found a way around my issues, but it still has me scratching my head.

    I added another field to my custom table - Prior Phase. OnValidate of Phase:
    IF Phase <> xRec.Phase THEN
       "Prior Phase" := xRec.Phase;
    
    OnModify:
    IF Phase <> "Prior Phase" THEN BEGIN
       SendPhaseChangeEmail(Rec);
      "Prior Phase" := Phase;
    END;
    

    The catch is that the email does not send until a user leaves the record or closes the Form (when it finally calls OnModify naturally). If I try to call MODIFY(TRUE) in my code, the UI fails to update (as described above) without a screen refresh. I guess I can live with that. any other thoughts are welcome.
    kind of fell into this...
  • jversusjjversusj Member Posts: 489
    follow-up:

    We discovered a fatal flaw in my earlier solution.

    The form that displays this record has a subform of lines. We found that if a user made a change to the Phase field and then immediately clicked into the subform, the NAV client would crash and close. Reopening the client and returning to the record revealed that the change to phase was rolled back (as expected). If I turned debugger on and clicked into the subform, the client would not crash. I have to think that the addition of debugger was providing something at runtime that prevents the client from crashing - perhaps the change in focus from the client to the debugger?

    I tried many other experiments (update the phase field by using a variable field, calling a codeunit that calls a processing report a la e-ship order acknowledgments, etc.) but was unfortunately able to resolve this in a satisfactory method. A third party tool is not an option, so I made the best of the situation. I added a boolean field to the table that gets set true when the Phase is changed. I then created a processing report that runs periodically and sends emails for those records where the flag is true. After the email is sent, the flag is reset. This works but is not ideal. Thankfully, the change in phase is not something that requires immediate notification to the user group so this "batch" approach is okay for now.

    has anyone else created a basic workflow similar to this in NAV where a field change is accompanied by an automated email? If so, how did you get around some of the issues I have encountered?
    kind of fell into this...
  • FlowerBizFlowerBiz Member Posts: 34
    has anyone else created a basic workflow similar to this in NAV where a field change is accompanied by an automated email? If so, how did you get around some of the issues I have encountered?

    I discovered that it doesn't work. Seriously, consider using the change log function and then use NAS to check the change log periodically and send messages based on the change log table instead of sending messages via the live form or table. If your business flow depends on immediate notifications, I would not use the standard NAV SMTP code. There are lots of other solutions, some using third parties and others using creative programming outside of NAV. For instance, your table or form could simply update a file outside of NAV that triggers a notification process, via named pipes, sockets, or a simple text file and watchdog program.
Sign In or Register to comment.