System Integration

Tampa 2007 Code Camp OBA Slides

dbottjer — Wed, 18 Jul 2007 12:29:00 GMT

I want to thank everyone who attended my session on Saturday. I had been sick all week and was still feeling quite run down but we had some great discussions. Office Business Applications (OBA) are really an excited way to look at developing or extending line-of-business applications. As promised here are my slides and some important OBA links.

Download Tamp 2007 Code Camp OBA Presentation
Supply Chain Management OBA Reference Pack
Loan Origination Reference Pack

Office Business Applications Architecture Talk With Colin Cole

dbottjer — Thu, 24 May 2007 23:27:00 GMT

The following conversation is a conversation with Microsoft Financial Services Sr. Architect Colin Cole discussing Office Business Applications (OBA). This is a new type of blog post for me and a Drowning In Technical Debt first. I hope to conduct similar conversations in the future. Finally, I would like to thank Colin for making time to have this conversation with me.

dbottjer says: So I figured a good place to start would be with a definition. What is OBA? I did some research and here is what I came up with. Office Business Applications (OBA) use the Microsoft Office Suite of programs (Outlook, Word, Excel, etc) as a presentation layer for connecting line of business applications and executing business processes.

Colin Cole says: Cool, I have a few more things.

dbottjer says: Ok great.

Colin Cole says: OBA is kind of the centerpiece of what we call a "people ready" solution.

Colin Cole says: It’s really about designing a solution to give the end user more control and agility to interact with the application. Rather than having the IT defined screens with text boxes and validation.

dbottjer says: The user has more control to personalize.

Colin Cole says: You get instead something that brings data down to the tools you're familiar with (as you state), but also have server piece as well and that's where office server (SharePoint) comes in. By exposing data through something like a SharePoint the business user can define their own reports bring the data down to a cube and open it up in excel. Slice and Dice. Create a dashboard.

dbottjer says: Right

Colin Cole says: Define their own KPI's. Etc. So like you state -- leveraging familiar tools, but also interacting with the solution data as appropriate for their role.

dbottjer says: So this leads to the Problem. I thought that a good problem definition is: a fundamental inconsistency between how business systems work and how people work.

Colin Cole says: Agreed

dbottjer says: Basically applications today are very rigid

Colin Cole says: Absolutely, take an investment scenario for example. The investor interacts with the canned application to analyze their portfolio. But there's always 5-6 things they want to know to make business decisions that aren't available. So what do they do? They call IT and ask for a new report. 2 months later they get their report. But by that time the need is totally different.

dbottjer says: Exactly.

Colin Cole says: So the reality is they don't even bother....and just create their own one-off spreadsheets that aren't reused, etc.

dbottjer says: So if they have an export feature they could export to Excel and do some quick processing there.

dbottjer says: But that is an one-off.

Colin Cole says: Right.

dbottjer says: So the idea of OBA is just to allow users to work in tools like Excel to begin with an augment excel with the missing services necessary for the problem domain.

Colin Cole says: Right, as well as interacting with dashboard/reporting type functionality bringing down tasks into Outlook, --like I showed you guys with our lending solution. Stuff like that.

dbottjer says: I guess this leads us to why use OBA? OBA's offer a familiar interface – Most business users are familiar with at least one or more programs within the Microsoft Office Suite. For example, Outlook is commonly used groupware that remains open throughout the business day on many corporate desktops. It would seem like a win-win situation to take advantage of a program that users are already familiar with and that is running on their desktops. Excel.

Colin Cole says: Exactly, why not plug a CRM tool into Outlook, since the sales folks are already familiar with the paradigm?

dbottjer says: OBA integrates line of business applications such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Supply Chain Management (SCM) in a presentation layer the user is already familiar with and productive in. For example, a sales associate may depend heavily on Outlook to communicate with his/her clients. The associate keeps To Do lists within Outlook and a calendar of all meetings. Integrating the sales associate’s Outlook with CRM would centralize all the company’s customer information. This would give the sales associate a place to add customer notes and perhaps a way to look up additional customer information such as support cases.

Colin Cole says: Exactly.

dbottjer says: So it seems like an efficient model for developing line of business applications?

Colin Cole says: Right, obviously not for everything, but some % of apps it's a better fit.

dbottjer says: Something else I noticed is that OBA is a great reuse story. For example, to implement an OBA solution you use an office product like Word, Excel, Outlook, SharePoint, etc. You also can use existing web services. Furthermore, you use VSTO and .NET.

Colin Cole says: InfoPath plays nicely as well. Especially the server forms stuff. Very cool, each InfoPath form can have C# Code Behind, just like aspx. It makes for a simple model to build professional looking web pages.

dbottjer says: So OBA is a culmination of technologies to provide a business solution designed for how people work. It seems like OBA's have the potential to have a big impact in the line of business application space.

Web Services and UTF8Encoded ByteArrays

dbottjer — Tue, 01 May 2007 10:06:00 GMT

Our business partner began reporting all bullet points were being converted to question marks during the archiving of Word Docs. An early hunch that perhaps our FTP component was defaulting to ASCII transfer mode instead of Binary proved incorrect. With this option ruled out we knew our electronic document repository was properly receiving both the control file and the Word Doc. We began to suspect the web service exposed by our application which returns a document and metadata for archiving. We were using a byte array to store, in this case, the word document and write it to the http response stream. However, we were not specifying the encoding type which was our fatal mistake.

1: StringWriter sw = new StringWriter();

   2:  XmlTextWriter xw = new XmlTextWriter(sw);

3:

   4:  // Save Approval Document to Text Writter.

   5:  doc.WriteTo(xw);

6:

   7:  // Added this line to specify encoding and resolve bullet point issue.

   8:  UTF8Encoding encoding = new UTF8Encoding();

9:

  10:  // Convert Approval Document To Byte Array.

  11:  byte[] docAsBytes = encoding.GetBytes(sw.ToString());

12:

  13:  vvDoc.FileBinary = docAsBytes;

ADSystemInfo Object Failing

dbottjer — Sat, 20 Jan 2007 12:24:00 GMT

Hacking my work laptop seems to be a regular occurrence lately. Like most enterprises ours applies active directory policies that affect our machines. Some policies make testing beta versions and new releases of software ahead of the official rollouts difficult.

After logging into the corporate network, over VPN, I noticed my login scripts weren’t running like they usually do. Normally, after a successful connection a message box displays a welcome message.

Curiosity got the best of me so I ran the script manually and began debugging.

Option Explicit

Dim Shell, netSys

 

Set Shell = WScript.CreateObject("WScript.Shell")

Set netSys = WScript.CreateObject("WScript.Network")

 

Dim  strUsrDomain

Dim oInfo, LDAPUsr

 

strUsrDomain=netSys.UserDomain

 

' Some machines have had problems accessing Active Directory information so these section

' captures any errors and stops the script if there are any

Set oInfo = CreateObject("ADSystemInfo")

If err.number <> 0 Then

            shell.popup("Error creating oInfo object " & e.description)

            WScript.quit(1)

End If

Set LDAPUsr = GetObject("LDAP://" & oInfo.UserName)

If err.number <> 0 Then

            shell.popup("Error creating LDAPUsr object " & e.description)

            WScript.quit(1)

End If

The script was failing while trying to get the username from the oInfo object (oInfo.Username line: 20). I began wondering if the problem was a permissions issue. To test my theory I set gave my network login read access to the following DLL’s:

AdsLocator.dll

Activeds.dll

Finally, I tried running the login script again and it work perfectly.

Registry Scripting

dbottjer — Thu, 18 Jan 2007 10:31:00 GMT

Editing the registry can be a time consuming process. Sometimes updates or cleanups are easier to perform via a registry script (.reg). A registry script can be created using note pad. For a registry script to execute properly the first line needs to be either REGEDIT4 (Windows NT4, Windows 2000, Windows XP) or Windows Registry Editor Version 5.00 (Windows 2K and Windows XP).

So a script would look like:

REGEDIT4

[HKEY_CURRENT_USER\SomeKey]

"SomeValue" = "ON"

Systems Integration: No Assumptions

dbottjer — Tue, 31 Oct 2006 07:51:00 GMT

There are many sayings about assumptions and I’ll let you fill in your favorite. Regarding Systems Integration, the hard lesson I’ve learned is not to assume the other system will properly filter or handle a specific constraint. For example, Windows systems use a carriage-return-line-feed to mark the end-of-a-line. However, UNIX systems simply use a line-feed to mark the end-of-a-line. This is not to say that UNIX systems can’t handle files containing CRLF’s. It just means that most UNIX Systems just use an LF to mark the end-of-a-line.

When writing code to integrate a Windows based system and a UNIX based system that transfers data through a file based feed, noting and handling this simple end-of-line difference can save much time and yes stress. Having a simple tool like NotePad2 in your arsenal is a great way to inspect your feed at various stages to ensure compatibility between the systems.

NotePad2 (http://www.flos-freeware.ch/notepad2.html) is a small, powerful replacement editor for “NotePad” which comes with Microsoft Windows. This tool is worth a look especially for its ability to show hidden characters such as those marking the end-of-line.

To handle the case described above I would recommend implementing a simple scrubber that removes carriage returns (CR's) from the end of each line before sending the file to the UNIX System. Here is an example scrubber:

using System.IO;
using System.Text.RegularExpressions;

public class UnixStripperActivity
{
    public static void SripCarriageReturn(string filePath)
    {
         string output;
         FileStream fs = File.OpenRead(filePath);
         StreamReader reader = new StreamReader(fs);
         string input = reader.ReadToEnd();
         reader.Close();
         fs.Close();
         output = Regex.Replace(input, @"\r", "", RegexOptions.Multiline);
         FileStream fsw = File.OpenWrite(filePath);
         StreamWriter sw = new StreamWriter(fsw);
         sw.Write(output);
         sw.Close();
         fsw.Close();
    }
}