| Email to SMS from Microsoft Dynamics CRM? |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through April 16, 2015 ⬆ |
◄ ► |
| Author | Message | ||||
| Anthony Dyson New member Username: Dysona Post Number: 13 Registered: 08-2010 |
Is anyone out there using NowSMS in combination with Microsoft Dynamics CRM 2013 to send SMS messages? We were intending to do this using Email-to-SMS, but now that we have all the mail routing working, we've discovered we have a compatibility problem. NowSMS requires a plain text body, it seems, and cannot work with HTML mail. By default, CRM sends HTML mail without an alternative plain text body. So far we haven't found a way to convince CRM to be a good citizen and send either plain text or multipart. If anyone has solved this issue or has any helpful suggestions, we would love to hear from you. Considering NowSMS does everything else we need, it would be a shame to have to look for an alternative at this stage. Anthony Dyson | ||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4992 Registered: 08-2008 |
Hi Anthony, We're going to investigate adding the capability to strip HTML when there is no alternative plain text body. I can't promise aa real quick turn around, but conceptually it is not a very difficult task. It would help if you could capture a few samples. Unless you are familiar with packet capture utilities, the easiest way to do this is to get the raw message data out of the MMSCDEBUG.LOG. You need to enable an extra debug setting for the raw message data to be logged ... edit MMSC.INI and under the [MMSC] header, add DebugFull=Yes. Debug=Yes must also be set to enable the MMSCDEBUG.LOG. Email any examples to nowsms@nowsms.con with Attention: Des in the subject line. -- Des NowSMS Support | ||||
| Anthony Dyson New member Username: Dysona Post Number: 15 Registered: 08-2010 |
In case anyone else is trying to do this: we've found a solution that works in our environment. We are using an on-premise Microsoft Exchange server to provide mail services to Dynamics CRM. - set up Dynamics CRM to communicate with Exchange via Exchange Web Services (EWS), not SMTP/POP - set up our Exchange server for ourdomain.org as the public mail exchanger for NowSMS sms.ourdomain.org - configured sms.ourdomain.org as a remote domain (not just an accepted domain) - set the ContentType parameter for the remote domain to MimeText instead of the default MimeHTMLText This causes Exchange to send a plain text mail body. It only works if you use a native protocol to communicate with Exchange, i.e. if you relay via SMTP it has no effect. The source of this tip is here: http://ezinearticles.com/3834297 Anthony | ||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5021 Registered: 08-2008 |
Hi Anthony, Thanks for sharing that information. I am glad you were able to find a solution. Perhaps a little late for your needs, but we did finish adding the capability to strip text from HTML when multipart/alternative is not used. An update that adds this is at http://www.nowsms.com/download/nowsms20140829.zip. -- Des NowSMS Support | ||||
| Anthony Dyson New member Username: Dysona Post Number: 16 Registered: 08-2010 |
Thanks, that's great and it gives us extra flexibility. What would also be fantastic would be if the gateway could convert from the code page of the source mail to UTF-8, instead of requiring the source message to be composed using UTF-8. Once again it's Microsoft Dynamics CRM causing us difficulties. It's automatically using us-ascii for harmless messages, iso-8859-6 for messages containing Arabic characters, etc., and we haven't yet found a way of convincing it to just always use UTF-8 regardless. This is resulting in corrupted messages, because it seems the GSM side expects UTF-8. Ho hum. | ||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5047 Registered: 08-2008 |
Hi Anthony, Can you provide some raw message examples? (Feel free to email like before.) NowSMS should be looking at the charset parameter for the Content-Type, and it should recognize iso-8859-6. -- Des NowSMS Support | ||||
| Anthony Dyson New member Username: Dysona Post Number: 17 Registered: 08-2010 |
It's recognizing that it's iso-8859-6 and flagging an error. 19:40:02:890 [13] ThreadRouteSMTPIn: charset= 19:40:02:890 [13] ThreadRouteSMTPIn: iso-8859-6 19:40:02:894 [13] UTF8StringRequiresUnicodeEncoding: Translate to/from GSM string results in loss of data I'm not sure how to interpret this message. The string itself is in the attached log file.
Somewhere in the chain the message is getting corrupted. What arrives on the phone contains a mix of arabic characters and accented english characters. | ||||
| Anthony Dyson New member Username: Dysona Post Number: 18 Registered: 08-2010 |
The previous raw message examples are still valid, actually. Because none of us can read Arabic, the best way to test whether they're correctly converted and delivered is to send one both to a normal email address and per SMS to a phone, and compare both renderings. | ||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5048 Registered: 08-2008 |
The log entries look good. It is basically a test, indicating that the message cannot be represented in the GSM character set, so Unicode will be used. The good news is that it looks from the log like the iso-8859-6 content has been converted to utf-8, because I see Arabic in the first string. The second string is what happens when an attempt is made to encode in the GSM character set, which fails, so the utf-8 version will be used. As a sanity check, have you tried sending Arabic from the NowSMS web interface? (Just cut & paste, as I don't read it either.) I'm wondering if the issue is not email specific. -- Des NowSMS Support | ||||
| Anthony Dyson New member Username: Dysona Post Number: 19 Registered: 08-2010 |
Sending from the NowSMS web interface works as it should. (Visual comparison!) Going back to the email-to-SMS problem: In the MMSCDEBUG log, the first string containing the Arabic characters is already incorrect. The extended characters (non-western) are all incorrectly mapped. It could well be that the problem is arising at the interface between CRM and Exchange, rather than the interface between Exchange and NowSMS. We'll pursue that line of investigation. | ||||
