Remember Sammy Jankis

Hi,

MOSS Workflows are great for Document Management process. There are many OOTB DMS templates in MOSS and you could leverage those activities with SharePoint Designer. I had a customer that wanted a process that used the Docx file format for authoring/approving the document and convert it to PDF file format before sending outside of the organization. My first idea was to use the Office 2007 capabilities in converting Word to PDF. You can do it easily in the Save As dialog so coding this shouldn't be a problem.

However, this will require installing Office client on the MOSS Server and this is not supported and not recommended. In my early 2003 days, I've tried to use the Word Spell Checker in ASP.Net Server and found it to be a very bad performance idea (and don't forget the many ghost WinWord.exe processes that you find in the task manager's memory) that was quickly replaced with a 3^rd party solution.

So nothing in life is free – but what about licensed solutions. I would recommend checking out ActivePDF tools. ActivePDF is the leading provider of PDF generation, conversion and development tools and they provide many tools and SDK for server Word to PDF conversion. You could easily wrap the conversion process (which is very easy once you have the SDK) inside a WF Activity and allow reusing it in many places around your Document Management System.

Find it here:

http://www.activepdf.com

Bye,

Adir Ron.

Hi,

It's been a while since I posted. As you may imagine, July wasn't the most popular month to spend in the office (or in the Office Server). However, I'm back and packed with loads of new information so it's sharing time! The main topic of this post will be InfoPath Development. Recently, I've been dealing a lot with InfoPath's browser forms with one of our customers (Shlomy, Sveta and Tal from the IDC – this post is dedicated to you) and while working I got the notion that many times developers tend to dismiss the fact that InfoPath is actually a full development platform and should definitely be treated as one. This is even especially important once you decided to add managed code and combine it with Visual Studio 2005/2008. Given concepts and best practices that we use in every development process are totally overlooked when you use InfoPath – and we're talking about important and time saving things like naming convections, data access layers etc.

Well, I decided to try and provide the basic Best Practices that you need to use with InfoPath forms. I believe this will add some sense into the development process and help you make the most of your time (and for other developers to maintain and debug your InfoPath forms):

Coding Naming conventions for InfoPath:

• Controls are Controls even if you design them in InfoPath. I'd recommend following Brad Abrams' C# style guidelines here:  http://blogs.msdn.com/brada/articles/361363.aspx
• FxCop 1.35 is always a great recommendation and especially in InfoPath. I'd suggest using this as early in your coding cycle as possible: http://code.msdn.microsoft.com/codeanalysis/Release/ProjectReleases.aspx?ReleaseId=553
  

Data Access Layer in InfoPath:

• If you want to query data from a SQL database in InfoPath Forms Services - this great resource is a must to design a good approach for your DAL: http://office.microsoft.com/en-us/infopath/HP100928231033.aspx?pid=CH100598301033
• Important Notion - If you design your form template based on the SQL database then InfoPath will generate queryFields whose values may be used to constrain the query.  If you use a secondary data connection to the SQL database, then you'd have to use custom code to constrain the SQL query based on the form's current state.
• Complex Data Connections should also be managed somehow just like every other development project. You'll definitely need to look at the new Data Connection Library (DCL) support for InfoPath data connections.  If you never heard of it or want to read more about it - see these superb articles for more details: 
• http://msdn2.microsoft.com/en-us/library/bb267335.aspx
• http://blogs.msdn.com/infopath/archive/2006/10/02/Data-Connections-in-Browser-Forms.aspx
• http://blogs.msdn.com/infopath/archive/2006/10/30/the-anatomy-of-a-udc-file.aspx
• http://blogs.msdn.com/infopath/archive/2006/10/05/Where-do-UDC-files-come-from_3F00_.aspx
• http://blogs.msdn.com/infopath/archive/2006/06/14/advanced-server-side-authentication-for-data-connections-part-1.aspx
• http://blogs.msdn.com/infopath/archive/2006/06/27/advanced-server-side-authentication-for-data-connections-part-2.aspx
• http://blogs.msdn.com/infopath/archive/2006/07/03/655611.aspx
• http://office.microsoft.com/en-us/infopath/HA100929071033.aspx

Digital Signatures for InfoPath:

• Support matrix (signing is only supported in IE, but all browsers can view previously created signatures). More data in here:  http://office.microsoft.com/en-us/infopath/HA102040851033.aspx#5
• Signing is performed using an ActiveX control.  In a Production environment, you should secure the connection via SSL in order to ensure the security of the signed data.
  

General Links:

• Team blog: http://blogs.msdn.com/infopath
• Office Online help: http://office.microsoft.com/en-us/infopath/FX100647031033.aspx?CTT=96&Origin=CL100607051033
• MSDN InfoPath developer resource: http://msdn2.microsoft.com/en-us/office/aa905443.aspx
• My previous post about InfoPath that is loaded with awesome links for InfoPath: http://blogs.microsoft.co.il/blogs/adir_ron/archive/2007/05/22/Huge-list-of-InfoPath-2007-Resources_2C00_-Links_2C00_-HOL_1920_s-and-mo.aspx
  

Oh, and before we set off – another link you should be aware of. Check out this great post that compare InfoPath rich client to InfoPath Forms Services. It covers all of the main differences and should be used before you decide on a complex form's platform:

http://blogs.msdn.com/infopath/archive/2007/02/16/all-you-wanted-to-know-about-browser-compatibility.aspx

That's it for now. See you soon…

Adir Ron.