Stored in File System - EMAIL with PDFs & path attribute????

Jaymer

In the context of Emails,
(edit. THIS IS FOR OUTGOING EMAILS AND THEIR ATTACHMENTS)
If I have an attachment of Document type, then its either stored in the DB or in the File System.
I had this working fine using the default - "stored in the db".
Added a path attribute and altered the field to use "stored in File System".

So if I make an Invoice Presentation, and use EXPORT DOCUMENT PrintedInvoice TO FILE 'c:/somedir/Inv0001.PDF'
then a file is created properly at that loc.
In order to EMAIL that PDF, is it correct that I have to:
CREATE OutgoingEmailForm WITH <vars>
[ AND STILL have to ]
IMPORT DOCUMENT OutgoingEmailForm.Attachment(s) FROM "the path(s)"

I then EDIT the created form for additional email settings...
And then I run the SendEmail process.
It takes 45 seconds to send my email with 2 attachments AFTER I save the OutgoingEmailForm (and about 10-15 seconds for it to come up, which is time to generate 2 PDFs and Import them)

Seems like if the file is already on the server where Aware is running, then it should be able to attach the files "over there".
as a test, I skipped the IMPORT DOCUMENTS and I know I had the ATTACHMENT PATH exact to the created PDFs, but my email arrived with no attachments.

I'm missing something significant here.
CRM was the basis for this app. so some of that was copied in (by another developer), but it follows that structure of doing emails.
Not much in the UserGuide. Searched for all "file system" and "stored in" references. No real help there.
Nor is there much in the forum... kinda hard to find with the existing search mechanism (but I did find a thread and cleaned up 9000 files in my temp directory 😃 )
Sure could use some help.
Thx
jaymer...

ACDC

This works for me :

I have the Invoice stored on the Invoice object.
So the Create Email process Exports the Invoice
Then IMPORTS it to Invoice.InvoiceDoc

Then when creating the OutgoingEmail from the Invoice , (the create email part of the process)
ENTER NEW OutgoingEmail WITH OutgoingEmail.Attachment1=Invoice.InvoiceDoc, etc etc.

So the Document is already in place before the email process begins

tford

ACDC,

I must be missing something. So are all invoices in your system held in both the file system and an instance of the Invoice BO?

ACDC

The Invoice.InvoiceDoc attribute is set to the file system by default (It used to be DB)

You could drop the EXPORT .. part and replace it with a process rule such as Invoice.InvoiceDoc='InvoiceDoc'

So yes , the document is stored on the Invoice Object referenced to the file system and a copy is also stored on the OutgoingEmail object. So if the invoice changes and another email is sent the two emails reflect the right document

Jaymer

ACDC wrote
This works for me :

I have the Invoice stored on the Invoice object.
So the Create Email process Exports the Invoice
Then IMPORTS it to Invoice.InvoiceDoc

Then when creating the OutgoingEmail from the Invoice , (the create email part of the process)
ENTER NEW OutgoingEmail WITH OutgoingEmail.Attachment1=Invoice.InvoiceDoc, etc etc.

So the Document is already in place before the email process begins

First of all, thanks for the reply.
I think I'm doing the exact same thing you were doing. I reread my post. I generate the invoice PBF, create an email and import it in.
Seems to be the exact same thing you were doing.
So now we have the PDF physically on the file system where it was just a temporary file, because once it is imported it can be removed. Then the PDF is actually stored in the database in the email object. And, I am relatively new at this, but I think the consensus on the Forum is to not store these documents in the database. Which is kind of the point of my post.
If I use the stored in file system / required attribute method, then exactly how is that saving the database from taking the hit of having to store the PDF in the database (or really in my case, even large photographs).
Plus, I'm not actually able to use this method which again is the purpose of the post.

Jaymer

ACDC, we were both replying at the same time.
You say that a copy is stored in the file system, but it's not in use by anything in the file system. You didn't save resources (disk space OR overhead) by saying to save it in the file system. In fact even without saving it in the file system and storing it in the database, it's still in the file system [as a result of the EXPORT DOCUMENT which was needed to generate the report]. Unless you run a purge to delete the temporary files after they are imported.
What I am missing is how to do this by having the document exists only in the file system, and not stored in the database object. I cannot get that to work and attach for an email.

ACDC

I skipped the IMPORT DOCUMENTS and I know I had the ATTACHMENT PATH exact to the created PDFs, but my email arrived with no attachments.

I assumed you had a failure and provided what works for me -
It seems you are importing into the OutgoingEmail object and my solution instead does OutgoingEmail. Attachment1=Invoice.Invoicedoc

As to the File system vs DB - you could make the attachments in OutgoingEmail point to the file system instead of DB ( I have not done this yet)

If I am still not making sense , then apologies .......had a loooong day

Jaymer

Acdc
I am only interested in outgoing emails, and I modified the original post.
You say you have not tried the part with the outgoing path, and I have tried that, and that's the problem. I cannot get that method to work. I can only send email with an attachment, if I do an import document and physically load it into the database, which is what I am trying to avoid.

Jaymer

tford wrote
ACDC,
I must be missing something.

You're missing something,
I'm missing something,
we're all missing something!

ACDC

So you have changed the OutgoingEmail.Attachment1 to file system.

Instead of Exporting and Importing have you tried :

CREATE OutgoingEmail WITH OUtgoingEmail.Attachment1='PresentationName'

Jaymer

(trying that now) - thx

ACDC

Also , when you change a document attribute from DB to FS it must be done according to procedure

Rule on the object to create the path IF Object IS NEW
All existing OutgoingEmail objects must be updated to reflect the path. (before switching the Document Attribute to FS , update all objects so the path is in place, then switch over to FS)

Jaymer

fair enough, but in my case I had no existing rows (new file).

Jaymer

FYI - Lets say your Attachment field is Attach1 in your OutgoingEmailForm BO.
Behind the scenes (in MySQL at least) AIM has created TWO fields:
Attach1_DOCTYPE (varchar200)
Attach1_DOCDATA (tinyblob)

After changing my code, per ACDC (explained later), I have the following data showing up in MySQL:
Attach1_DOCTYPE: 020272495469116503_RDDoc2554125968157462316.PDF
Attach1_DOCDATA: {null}

BEFORE his change, when I was afraid the PDFs were being stored in the DB, it looked like this:
Attach1_DOCTYPE: c:\PDFOutput\Invoice123.PDF
Attach1_DOCDATA: {binary}

AND, I have verified by looking at the physical database files (in MySQL: outgoingemailform.ibd) that the PDF IS DEFINITELY NOT STORED in the database (the new file is still only a few K in size, as opposed to 18Meg for the same file earlier).

Jaymer

I had seen another forum post about "long meaningless filenames", and now I have them.
Even though the file is named "perfectly" at the server (Invoice123.PDF), doing it using this method generates the bogus object name... and thats what shows up when the customer gets his email. Attachment named "020272495469116503_RDDoc2554125968157462316.PDF" which in no way is acceptable.

Initial method to send an email with the invoice attachment:
this method stored the file in the db
EXPORT DOCUMENT 'invoice' TO FILE 'Invoice123.PDF"
CREATE outgoingemail WITH ..... {basic fields}
IMPORT DOCUMENT outgoingemail.attach1 FROM 'Invoice123.PDF"

Now, add change to store on file system and add a Attach1_PATH field. I also put a RULE on the Path to set it WHEN NEW.
NOT NEEDED EXPORT DOCUMENT 'invoice' TO FILE 'Invoice123.PDF"
CREATE outgoingemail WITH ..... {basic fields} PLUS
outgoingemail.Attach1='Invoice_Report"
ONT NEEDED IMPORT DOCUMENT outgoingemail.attach1 FROM 'Invoice123.PDF"

So, a bit simpler. i'm running the report just by assigning it to a field in the email. Problem is, it creates a random, unique filename for the report.
The benefit is that is TRULY is stored on the server.

NOTE: So far, the only benefit is that the file is saved ONLY on the file system and not in the DB. It still takes the same time to run the report (in my case I really run 2, and have 2 attachments) and still takes the same amount of time to send the email (45 seconds). (1 attachment is 25k, and the other test one is 13Meg. Many will be bigger than that.)

The key would be to find someone out there who is:
*) Generating a report to attach to an email
*) Not storing in the DB
*) Getting an attachment to be sent as a useful name

jaymer...

ACDC

You may have to use EXPORT to filename ... and then IMPORT to control the filename and then delete the File after the process has run

Jaymer

Thats the way I had it in my initial post.
But I could not get that to NOT store the binary in the BO.

ACDC

So whats wrong with that ? why don't you want to store the document on the Invoice object like I suggested in the first place

Prepare the Document and store it on the Invoice Object and then Create the email with Attacment1 =Invoice.Document

Then go back and delete the Exported file.... and the FS image if you must

Jaymer

I don't want or need to delete the FS image.
I DON'T want the PDF stored in the blob datatype in the MySQL database - I think i've said that at least 3 times in this post.

You wrote:
why don't you want to store the document on the Invoice object like I suggested in the first place

Is that the same as:
why don't you want to store the PDFs (20 MB in size minimum) in the Email object?

Answer:
because thats why there is a Store on FS option, and I want to use that... but the filenames are wonky then.

you wrote:
Then go back and delete the Exported file.... and the FS image if you must

These are the same, right?
I do a EXPORT DOCUMENT to a filename, and thats the same one I'd link to (via the Path attribute) and save forever on the FS

ACDC

I DON'T want the PDF stored in the blob datatype in the MySQL database - I think i've said that at least 3 times in this post.

Huh - Who said its In Mysql - all references I have made are to a Document attribute with FS set

After further thought, you should be able to do this:
EXPORT the document to the same path as the Attachment1 path is set. This way you can name the file ( you don't have to do the IMPORT as its already referenced in the OutgoingEmail.Attachment1 path setting )

So when you send the email Attchment1 is already in place