Skip to main content

Hi Community,

First post :)

I have an IMAP publisher which downloads GML attachments.

The files containing folder name is based on the email subject i believe. This seems to work perfectly when this file path is being processed by the Workspace subscriber. However, when the email subject contains an em/en dash character (i'm guessing anything not UTF8) the folder is then saved with the special replacement character in its name as shown.

Once the workspace runs, it tries to use a JSONFeature to read the Topic message but the filepath is incorrect. FME log shows something like the following;

XML Parser error: 'unable to open primary document entity '<FILEPATH>\\DBYD\\Incoming\\<FILENAME>_2??12_<FOLDERNAME>\\<FILENAME>_LLGDA94.GML''

 

Anyone any recommendations on how to deal with this please?

 

Many thanks

K

Hi @kieranmg,

What version and build number of FME Server are you seeing this problem with? I just tried a quick test with an email containing an em dash, but the path was created correctly and worked for me with FME Server 2019.1.

Could you paste an example of what the email subject line looks like with the em/en dash in there still? I'm wondering if perhaps I'm doing something a bit different and not replicating exactly what you're doing to hit this issue. Also, what kind of email server are you connecting to in the IMAP configuration?


Hi @kieranmg,

What version and build number of FME Server are you seeing this problem with? I just tried a quick test with an email containing an em dash, but the path was created correctly and worked for me with FME Server 2019.1.

Could you paste an example of what the email subject line looks like with the em/en dash in there still? I'm wondering if perhaps I'm doing something a bit different and not replicating exactly what you're doing to hit this issue. Also, what kind of email server are you connecting to in the IMAP configuration?

Hi @lauraatsafe,

Thanks for the followup. I'm using FME Server 2018.0.1 - Build 18310 - win64. Maybe there lies the problem!

This is part of our DBYD solution. Subject of email will usually take the form of something like 'DBYD JOB:178754785 SEQ:9874936478 - 54–86 fictitious street, Koroit, VIC 3267'

Usually the emdash is seen between numbers for street addresses, as above.

We're using exchange 2013 (soon to move to office 365)

 

 


Hi @lauraatsafe,

Thanks for the followup. I'm using FME Server 2018.0.1 - Build 18310 - win64. Maybe there lies the problem!

This is part of our DBYD solution. Subject of email will usually take the form of something like 'DBYD JOB:178754785 SEQ:9874936478 - 54–86 fictitious street, Koroit, VIC 3267'

Usually the emdash is seen between numbers for street addresses, as above.

We're using exchange 2013 (soon to move to office 365)

 

 

Thanks! I'll try testing this with 2018 and will let you know what I find.


Thanks! I'll try testing this with 2018 and will let you know what I find.

Hi @lauraatsafe, just wondering did you ever replicate this. I had it after upgrading to 2019 and even now on 2020


Hi @lauraatsafe,

Thanks for the followup. I'm using FME Server 2018.0.1 - Build 18310 - win64. Maybe there lies the problem!

This is part of our DBYD solution. Subject of email will usually take the form of something like 'DBYD JOB:178754785 SEQ:9874936478 - 54–86 fictitious street, Koroit, VIC 3267'

Usually the emdash is seen between numbers for street addresses, as above.

We're using exchange 2013 (soon to move to office 365)

 

 

Hi @kieranmg​ ,

Did you ever figure anything out for this? Having exactly the same issue with our DBYD response on 2020.

 

At the moment we've just implemented a workspace using the daily summary email to check that all our responses were sent, which helps us automatically find these. Then we forward them back to server with the em dash replaced. Not ideal but fortunately it's not happening very often.


Hi @lauraatsafe,

Thanks for the followup. I'm using FME Server 2018.0.1 - Build 18310 - win64. Maybe there lies the problem!

This is part of our DBYD solution. Subject of email will usually take the form of something like 'DBYD JOB:178754785 SEQ:9874936478 - 54–86 fictitious street, Koroit, VIC 3267'

Usually the emdash is seen between numbers for street addresses, as above.

We're using exchange 2013 (soon to move to office 365)

 

 

Hi Jarryd, I did, if I remember correctly I think it was to do with the Publication parameter 'Download Attachment to' .. I removed the optional value from here (i believe it may have been mandatory before 2020). I believe there were a few other character issues with the referrals mail itself, so we added stringreplacers to deal with slash(/) and question mark(?) characters popping up in the ADDRESS field.. hope this helps!

 

 


Reply