Extending Document Handling
Well I had a great development peice I had to work on. I was given the task to extend the standard document handling of Ax 3.0 for a client. Basically they wanted to use the folder / Archive piece so that documents where not stored in the database, but rather on a file server.
By default this can already happen. The hang up was that the archiving happened in one folder. So there was no real structure. Another bad point to this was that the naming of files used a number sequence. So what they wanted was to give a meaniful folder structure that the system automatically created based on the first two dimensions. Also they wanted to file name to be meaniful, where as it took on the primary field of the table and record it was associated with, plus a _MMDDYY_1+.xxx. So if it was associated with a Sales Order, then it would like similar to: SO00123_032706_1.pdf, and the next would be SO00123_032706_2.pdf.
As for the structure that wanted to supply the "default" folder location, like: c:\temp\ and then have the system auto crrate based on use something like this: c:\temp\01110\3475\. Again if the folder did not exists, then the first time a document was assoicated with a record, then the document handling code would have to grab the dimensions of that record, and then create the folder structue and then the file.
Here the first issue came into play, because what if there was not a dimension associated with that given table, record. If this was the case, then a prompt needed to ask the user what the two dimension values where. Well, in order to accomplish all of this I used reflection through the AppEntity class. This was a wonderful way to gather all this information based on the Common table that was passed in. Through the AppEntity I was able to check to see if a Dimension existed, if not prompt. If so take the value and use to create / use the folder structure. Then I was able to use the AppEntity class again to take and get the TitleField1 of the given Common table and pull the first part of the file name based on that. Now from here on forward this new document handling extension will work for any given table and record that a document is associated to a record.
Well for now that is it, and I can't give out the code to this solution but I can give you an line of code that shows you how I got the title field 1 of the passed in Common table:
entity.getFieldValue(fieldid2name(entity.dictTable().id(),entity.dictTable().titleField1()));
So if this was being associated with a Sales order, and the sales order was SO001234 then the value that is given from this line of code would be 'SO001234'. Same code would return, if it was a purchase order 'PO######' (Replcae # with actual numbers).
Well I hope this helps someone out. Reflection is a great way to code, because you don't always know what you are coding for, however you do know the desired end result.
To give you a little more insight, without revealing to much more code I only changed the DocuActionArchive class, and the DocuRef and DocuValue tables. These were small changes too as all my code went into a new Action class that I created. Well that's all for now, check back soon for more code examples, reviews, news, etc.
Find a job at: www.DynamicsAXJobs.com
By default this can already happen. The hang up was that the archiving happened in one folder. So there was no real structure. Another bad point to this was that the naming of files used a number sequence. So what they wanted was to give a meaniful folder structure that the system automatically created based on the first two dimensions. Also they wanted to file name to be meaniful, where as it took on the primary field of the table and record it was associated with, plus a _MMDDYY_1+.xxx. So if it was associated with a Sales Order, then it would like similar to: SO00123_032706_1.pdf, and the next would be SO00123_032706_2.pdf.
As for the structure that wanted to supply the "default" folder location, like: c:\temp\ and then have the system auto crrate based on use something like this: c:\temp\01110\3475\. Again if the folder did not exists, then the first time a document was assoicated with a record, then the document handling code would have to grab the dimensions of that record, and then create the folder structue and then the file.
Here the first issue came into play, because what if there was not a dimension associated with that given table, record. If this was the case, then a prompt needed to ask the user what the two dimension values where. Well, in order to accomplish all of this I used reflection through the AppEntity class. This was a wonderful way to gather all this information based on the Common table that was passed in. Through the AppEntity I was able to check to see if a Dimension existed, if not prompt. If so take the value and use to create / use the folder structure. Then I was able to use the AppEntity class again to take and get the TitleField1 of the given Common table and pull the first part of the file name based on that. Now from here on forward this new document handling extension will work for any given table and record that a document is associated to a record.
Well for now that is it, and I can't give out the code to this solution but I can give you an line of code that shows you how I got the title field 1 of the passed in Common table:
entity.getFieldValue(fieldid2name(entity.dictTable().id(),entity.dictTable().titleField1()));
So if this was being associated with a Sales order, and the sales order was SO001234 then the value that is given from this line of code would be 'SO001234'. Same code would return, if it was a purchase order 'PO######' (Replcae # with actual numbers).
Well I hope this helps someone out. Reflection is a great way to code, because you don't always know what you are coding for, however you do know the desired end result.
To give you a little more insight, without revealing to much more code I only changed the DocuActionArchive class, and the DocuRef and DocuValue tables. These were small changes too as all my code went into a new Action class that I created. Well that's all for now, check back soon for more code examples, reviews, news, etc.
Find a job at: www.DynamicsAXJobs.com
posted by brandon | 7:50 PM
1 Comments:
Good stuff Brandon!
Someone told me about your blog and it's great to see how you embrace the platform technology.
Tip: It is better to use the AppEntity.field(name,[value]) instead of set/getFieldValue.
Also, did you know that AppTable::recordFilename(Common) gives you a valid filename based on the titlefields? Furthermore, AppTools::recordString(str, Common) allows you to use a syntax like "C:\[AccountNum]\[SalesId].doc" to expand field values from a record buffer into any string, including filenames.
Did you check out how DMS Studio from To-Increase extends the document handling of Axapta?
Keep up the good work!
Petur.
Post a Comment
<< Home