Is Microsoft Changing Strategies On Silverlight?

This article was recently posted on ZDNet, detailing Microsoft’s diminished mentioning of Silverlight in their keynote.  From the article, it sounds like Microsoft is positioning Silverlight to become their mobile development platform, with HTML5 becoming their main cross-platform focus.

This change in focus correlates with the increased popularity of Apple’s iOS platform.  It makes some sense that Microsoft would want to avoid have a proprietary development platform on iOS, as Apple has been pretty hostile toward’s Adobe’s Flash platform.  I don’t see the longtime rival acting any differently towards Microsoft.  In this instance, HTML5 makes more sense when attempting to reach the populous iOS market.

If you wish to discuss Silverlight, HTML5 and iOS development with employees of ImageSource, come visit us at Nexus.

  

Microsoft.Practices.Unity Library

Recently, a development effort at ImageSource involved use of the Microsoft.Practices.Unity library, a part of the Microsoft Patterns & Practices.  The Unity piece provides tools for more modular, component based application design.  It provides simplified object creation and ability to specify object dependencies and parameters at runtime.  While I am still researching all that Unity can do, it looks like a very interesting and exciting new way to create component based applications.

For more information, see the MSDN Article about the Microsoft.Practices.Unity library.

VB Coding in a .NET World

C# is the standard coding language for developers at ImageSource, but it wasn’t always that way.  Before, VB.NET was the predominant language of choice.  When converting some of the codebases over from VB.NET, we consistently run into areas where VB.NET specific commands have been used.  These commands either do not exist in C# or require use of the Microsoft.VisualBasic library.  Either make code conversion very frustrating when they are used.

Below are some examples of commands that should be avoided in .NET code:

  • Cint, Cstr, CDate, CDbl – Use the equivalent call in the System.Convert class.
    • CInt – Convert.ToInt32
    • CStr – Convert.ToString
    • CDate – Convert.ToDateTime
    • CDbl – Convert.ToDouble
  • IsDate, IsNumeric – This one is a bit trickier and requires more work, but can be a lot more useful.  C# does not have an equivalent type checker, but you can use the TryParse methods located in the primitive objects.  For example, the following VB.NET code can be used to check if a string is an integer value.
    • Dim i As Integer = 0
      Dim test As String = "213"
      If Integer.TryParse(test, i) Then
        'Hey, this check worked!
        'And the integer has already been converted so you
        'can start using it.
      End If
  • VBCRLF – The new line command in VB, necessary because VB.NET does not allow you to write special characters in strings, so special characters need to be concatenated onto the strings.  Instead of VBCRLF, use the Environment.NewLine command, as this exists in both VB.NET and C#.
    • Optimally, code converted to C# should convert any instances of VBCRLF to \n in the string.  However, using Environment.NewLine will at least get it to compile without need for the Microsoft.VisualBasic library.
  • With - Avoid the With statement, as it does not exist in C# and you’ll just end up having to put the object reference in anyway.  It is not that much harder to just write the objectName.Method or objectName.Property, and it makes the code easier to understand.

So hopefully this brief overview will help you to write better VB.NET code.  Remember, the .NET framework exists in both VB and C# form, and making the two easily compatible helps code maintainability and portability.

ECM Best Practices: Integration with ERP

Integration with ERP is something most SE’s (Systems Engineers) and PMs (Project Managers) should keep in mind when designing a project.  ERP, or Enterprise Resource Planning, is the process of using modularized software and hardware within a centralized network and datastore.  In regards to ECM, proper integration with ERP is important for maintaining data integrity with the larger organization.  ImageSource has successfully incorporated ERP Integration with many of it’s customer partners.

As an example, ERP Integration can be done within an Oracle IPM Process Workflow, using a combination of scripts and forms to access the centralized data store for use within an IPM Package.  The centralized data is usually populated and maintained by sources within the organization, but external to Oracle IPM Process Workflow.

The following examples demonstrate how ERP Integration can be used to maintain data integrity.  In this example, we have a workflow package that requires 3 pieces of Vendor Information: the Name, Address and ID Number.  Information about all of our example organization’s Vendors is located in a pre-existing database.  We can harness this data within the workflow, using some techniques demonstrated below:

Script Screenshot

Oracle IPM Workflow Screenshot

The above screenshot illustrates one way that ERP Integration can be handled within a process workflow. The package would enter the workflow containing a rudimentary amount of metadata gathered during  the Document Capture phase.  It would then be processed by the Vendor Lookup Script, which would use data in the package (like the Vendor Name) to query the centralized data store for the appropriate vendor information (like Address and ID Number).  If matching data is successfully found, it would then populate the package with it.  From there, the package would move on to the Review Queue where all of that data would be made viewable to the user.

ERP Integration can also be handled within an IPM Process Workflow form.  Observe the ERP data lookup demonstrated below:

IPM Process Form with data populated from the Vendor Lookup Script.

If the user needs to change the Vendor Information, they can do so by clicking on the Vendor Name dropdown.  The dropdown list is populated with vendor names pulled from the centralized data store.

List of Vendor Names from the centralized data store.

Upon selecting a new Vendor Name, the workflow form performs a query against the data store for the matching vendor information, as pictured below.

Vendor Information after a lookup in the centralized data store.

As you can see, the only data that was needed was the Vendor Name.  The Vendor ID and Address were updated to reflect the change on the form.  This kind of ERP Integration keeps data intact and makes metadata capture easier for the user, as they do not need search through piles of paper or external applications to find the appropriate information.

Richard Franzen
ImageSource, Inc.

Share on Twitter

The DataContractSerializer – XML Files Made Easy

With the release of .NET 3.5, Microsoft has included a fun new tool for data serializing.  The DataContractSerializer was introduced as a replacement for the current XmlSerializer class, and is the preferred XML data serializer of developers at ImageSource.

The DataContractSerializer class uses opt-in properties for it’s serialization rather than the XmlSerializer class’s opt-out methodology.  This means that the programmer must specify what class properties are to included in serialization.  It’s also up to the programmer to serialize fields, properties and non-public data.

The DataContractSerializer class is nice because it is easy to use and easy to read in the code.  It just requires that all serialized properties be tagged with the DataMember attribute and the class itself be tagged with the DataContractAttribute attibute. To use this class, a reference to the System.Runtime.Serialization library must be added to the project.

Below is an example of creating a serializable class:

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Serialization;

namespace TestNamespace
{
  [DataContractAttribute()]
  public class TestClass
  {
    [DataMember()]
    public string Name
    {
      get { return _name; }
      set { _name = value; }
    }

    [DataMember()]
    public int Number
    {
      get { return _number; }
      set { _number = value; }
    }

    [DataMember()]
    public bool Enabled
    {
      get { return _enabled; }
      set { _enabled = value; }
    }

    [DataMember()]
    public List<string> Other
    {
      get { return _other; }
      set { _other = value; }
    }

    private string _name;
    private int _number;
    private bool _enabled;
    private List<string> _other = new List<string>();
  }
}

Saving the class and loading it from a file is incredibly simple.  It just requires an instantiation of the DataContractSerializer class and a call to either WriteObject or ReadObject, depending on whether it is a save or load operation.

Below is an example of saving an object to an XML file and then loading it back from the disk:

using (FileStream writer = new FileStream("c:/temp/file.xml",
  FileMode.Create, FileAccess.Write))
{
  DataContractSerializer ser = new DataContractSerializer(typeof(TestClass));
  ser.WriteObject(writer, testObj);
}

TestClass loadObj;
using (FileStream reader = new FileStream("c:/temp/file.xml",
  FileMode.Open, FileAccess.Read))
{
  DataContractSerializer ser = new DataContractSerializer(typeof(TestClass));
  loadObj = (TestClass)ser.ReadObject(reader);
}

Finally, here is an example of what that XML file looks like when opened in Internet Explorer:

xml_screenshot

So I hope this brief tutorial has been helpful.  The DataContractSerializer is nice for quickly creating objects for file settings, or when serialized XML data needs to be sent over a network.  It supports a wide variety of data types, as detailed on the MSDN site.

Share on LinkedIn   Share on Twitter

Distributed Capture & Document Capture

Distributed Capture & Document Capture

Capture is only a part of the ECM universe, but a crucial part nonetheless. Once a document is captured into an Enterprise Content Management system, it must be stored, perhaps put into a workflow process, archived, and made available for retrieval. Retrieval is in many ways the main thrust of an ECM system (no point putting it in there if you can’t ever see it again); retrieval is dependent on the index values associated it with it, which brings us back to capture.

Capture is the process of getting documents (and their data) into the system. Distributed Capture is the mechanism by which documents from a variety of locations (near and far) enter the system. The easiest way to do this is to utilize the file system. When different offices (or locations — work from home, anyone?) of a company are on the same network, specific locations on the shared file system can be designated for various purposes. Different directories can be used to input different kinds of documents.

I thought we were going to be paperless by now

This type of taxonomy works okay for existing electronic documents (Word files, spreadsheets, PDFs, etc); but what about hard-copy? The seemingly ubiquitous paper which exists in our so-called paperless office? Well, it needs to be scanned in. You want documents classified in a consistent manner, and the metadata (index values and other interesting info about the document) as accurate and as consistent as possible.

Consistency is key. When setting up a company-wide ECM system, it is a a key success indicator that everybody to follow the same set of procedures and guidelines involved in getting documents into the system. This can be accomplished by having a distributed capture system available.

The company I work for makes and sells a distributed capture system today. As we go through our roadmap discussions for where we want to take the product to solve customers’ future problems, we developers have have to grapple with some fundamental issues, mainly, what is the best technology to use as a platform.

It’s easy to imagine using the web to provide distributed document capture throughout your enterprise. You have centrally managed web servers. Everyone has a web browser on their computer (and cell phone, for that matter). In fact, anyone who’s ever attached a document using an html-based email program has already exercised the base technology necessary for a distributed capture system. One key advantage of Distributed Capture is that you get rid of paper at the source; take a moment to think about the implications of that. It’s okay, I’ll wait.

What else is needed…
There are two main improvements to simply uploading a document by way of a web page. One is the acquisition of the paper document, the other is the user-experience and business process to build into the hosting program. I’ll go into the physical acquisition in a later post, but the user-experience of a distributed capture system has to provide two things to be successful. It must be Dead Simple to Use and it must provide the functionality necessary to get good data into the system.

Our checking with users shows again and again that a single button is an attractive interface, with more functionality exposed as needed. One key question developers raise is what technology to build the interface in?

Technology Pros Cons
HTML Standards compliant, supported by all browsers. Primarily a static user interface. AJAX can add some Zing to the interface, but is problematical in certain situations (back-button, anybody?)
Flash Ubiquitous; Flash player in something like 90% of all browsers. Began life as an animation scripting language, although ActionScript 3.0 is more sophisticated. IDE support is poor. Hard to get my head wrapped around the timeline model.
Silverlight Microsoft integration and toolset. Microsoft has an army of developers working on tools and technologies; big changes in how Microsoft handles internet computing are emerging. Current market adoption is a little slow. Microsoft talks the big talk about cross-platform now, but has a history of embracing, extending, then co-opting technology (in my opinion)
JavaFX Ubiquitous. Many very good VM’s out there. Java itself is well suited to backend, server-side development. UI is not Java’s strong-suit; AWT ring a bell?
Platform Specific Code Leverage native functionality, look and feel. Lots of code bases to implement and maintain. Cross-platform toolkits and libraries tend to dumb-down the functionality to the lowest-common denominator.

I’m sure anybody reading this has ideas of their own about the pros and cons of the platforms listed out, and perhaps other ideas to add to the list. I welcome your comments.

Share on Twitter

Follow

Get every new post delivered to your Inbox.