Controlling DPL from Windows PowerShell

Are you using PowerShell yet?

PowerShell (aka POSH) is Microsoft’s latest scripting environment, consisting of a command line shell and an associated script language. Power users appreciate scripts because they’re a quick way to automate repetitive tasks that don’t warrant writing a whole new program. While PowerShell is broadly used among IT professionals, many Windows power users who could benefit from it don’t know it exists.

Historically, Windows has always been a shell-poor platform. In the bad ole days, a “Windows shell” was a humble DOS box on the screen, able to execute .bat files and a few file management commands but architecturally cut off from most of the actual OS it was running on. Would-be scriptors who had nontrivial work to do would write small programs, often in Visual Basic, which would pop up dialog boxes saying “Please wait…” or something equally vacuous. UNIX fans quite rightly scoffed at the pathetic state of scripting on the common man’s OS.

The situation gradually improved as the Windows NT architecture took over, but there was always the problem of getting inside the big boxes of monolithic Windows applications, like Word and Excel. A task that involved modifying Excel spreadsheets and performing file management commands might have to be awkwardly implemented as an Excel macro, or one of those “Please wait…” apps doing OLE Automation. To fully leverage Windows, a script has to be able to get inside those big applications that are the reason people run Windows in the first place.

PowerShell solves the problem of scripting in the shadow of big applications. PowerShell allows you to do everything you ever wanted to do in a batch file, but also dig into applications using .NET and OLE/COM technology. PowerShell works on objects, not on streams of text, so it can make those applications (including our favorites: DPL, Excel and PowerPoint) sing and dance.

The DPL API (available in the Enterprise and Portfolio versions) is based on OLE/COM Automation and can be easily invoked from PowerShell. Here’s an example of a script that loads a DPL workspace file, runs a decision analysis and then saves the results.

Add-Type -Path C:\Program Files (x86)\Syncopation\DPL8\DPL8wrap.DLL
$dpl = New-Object -ComObject DPL.Application
$ws = [runtime.interopservices.marshal]::CreateWrapperOfType($dpl.Workspace,[DPL8wrap.DPLWorkspaceClass])

Now, a bit about the formalities. Windows is the great application/object bureaucracy, and as in any bureaucracy there are times when a disinterested bureaucrat tells you to fill out a form. The Add-Type command causes PowerShell to load the types in DPL8wrap.DLL, so it knows what “DPL.Application” means (the wrapper DLL is not installed with DPL; email support to get it). The “CreateWrapperOfType(…” takes the Workspace member of DPL.Application and tells PowerShell that the variable $ws is of type DPL.Workspace. If we just took $dpl.Workspace directly, it would be of type System.__ComObject, PowerShell speak for something-I-know-not-what-support-of-OLE, and we wouldn’t be able to invoke it’s methods.

Now that you know how to get started using DPL from PowerShell, you can use all the API capabilities described in the documentation (primarily Chapter 5 of the DPL 8 Enterprise Manual). Moreover, you can just as easily reach into Excel and many other applications from the same script that’s controlling DPL. Want to run three versions of your DPL model with five versions of your spreadsheet and bung all 15 of those risk profile charts into PowerPoint? You can do it all from one PowerShell script.