sdOffice
2.0 Preview
sdOffice, since its initial release in
2001, has helped developers more efficiently and fully integrate non-Windows
"outside" applications with the MS-Office productivity suite and other
Windows-based software applications. The standard object technologies that
sdOffice supports include the following:
- Microsoft Excel
- Microsoft Word
- Microsoft Outlook
- MAPI (electronic mail via Microsoft MAPI)
- ADO (database acess via ADODB/ODBC)
new in sdOffice 2.0
- Email (email send/receive via SMTP and POP)
- System (access to system folders and the
Windows shell for launching tasks)
- Popup (pop-up messages)
- Preview (text report print preview)
With sdOffice 2.0,
the architecture has been re-designed from a "server within
a Windows client" to a three-tier client-server
model. One benefit of this new architecture will be to facilitate remote
client access to sdOffice, as the first release had
"issues" with remote connectivity due to firewalls.
The new architecture also allows a much-preferred
per-concurrent-job server licensing model, with a
free sdOffice client which can be installed on
any
number of workstations.
Another benefit of the new
architecture is the inclusion of a file distribution
utility which allows files to be stored on the
server for later distribution to workstation clients
as they connect to the sdOffice server.
An excerpt from the
introduction chapter in the sdOffice 2.0 user manual gives a
good background and overview of the product's uses,
capabilities and functionality.
sdOffice is a unique software tool that enables
access to Microsoft Office® and other Windows-based technologies from
non-Windows systems and applications. Any application or computer that
can interact with a TCP/IP socket or Unix/Linux pipe can now work with
Microsoft Office and other products, using sdOffice as the bridge to the
Component Object Model (COM) interfaces found in many Windows
applications.
COM is a method used in the Windows application
world to treat programs, such as Microsoft Excel® and Microsoft Word®,
as programmable objects from within other programs. This powerful
facility is an important part of the Microsoft Windows® platform, but
many legacy programming environments are not able to take advantage of
it. In addition, many applications today run in Unix and Linux
environments and have no direct way to access COM objects on Windows
systems.
sdOffice is the bridge that allows applications of
any sort to work with the COM object model for Microsoft Office.
sdOffice accepts commands from an application and translates them to the
appropriate COM methods, allowing applications written in virtually any
programming language, and running on virtually any operating system, to
control programs like Excel and Word in real time with a comprehensive,
extensible set of commands.
As an example of the sort of capability that
sdOffice provides, imagine the example of a traditional export to Excel
procedure used by many legacy software users. In the original effort,
the user runs a report that creates a tab-delimited or
comma-separated-value text file. The user then copies the file to their
PC, opens Excel, and imports the file. The columns in that file show up
in the cells in Excel, and then the work begins. The user begins
formatting the columns to match the data types and formats, adds column
headings, inserts a formula column, adds column totals or maybe some
grouped subtotals. Quite a while later, the Excel worksheet finally
looks like a finished document.
With sdOffice, that same report that started the
whole process can export directly to Excel and perform every one of
those formatting, formula, and totaling steps without any user
intervention. With that sort of automated functionality, the
application, rather than the user, performs all the work to produce the
finished document, saving a tremendous amount of time.
sdOffice is composed of several elements ......
|
THREE-TIER
ARCHITECTURE
The elements referred
to above form the cornerstones of the three-tier
architecture mentioned at the top of the article.
The three-tier client server architecture is
depicted in the following graphic, and discussed
below in excerpt from the user
manual.
sdOffice is composed of three elements:
- An sdOffice Network Server
- Windows-based Office clients
- Application clients
The heart of sdOffice is the Network Server. This
software runs full time in background, optionally as a service under
Windows, and as a daemon on Unix or Linux. The Network Server is the
interface point for both Office clients and Application clients.
The Office clients connect to the network server
when they start up, and maintain a persistent connection while waiting
for application clients to connect and initiate jobs. The Office client
is the piece that translates commands into COM object methods. The
Office client is similar to, but more powerful than, the old sdOffice
1.0 Windows client.
The Application clients connect to the network
server whenever a job needs to be executed on an Office client. The
Application connects to the Network Server, specifies which client and
which job object, and then begins sending commands. The Network Server
routes the commands to the appropriate client, and returns responses
back. Application clients include:
- The application software itself, if it can
work with a TCP/IP socket
- A Perl-based pipe for applications that can
use bi-directional pipes but not sockets
- sdRun executables (Perl-based on Unix/Linux,
native on Windows) which process the commands from a text file
- BBx and ProvideX wrappers around the above
features, providing a familiar CALL interface to programmers in
those languages
It is also possible to emulate an Application
Client using Telnet, or by using the Application window in the Office
Client’s visual interface.
|
OFFICE CLIENT
VISUAL INTERFACE
The Office client
which is installed on the Windows workstation(s) has
a new visual interface which automates a number of
management, control, and development testing
tasks.
Below is a preview of the new
client visual interface for sdOffice 2.0 .
Object Extensions With VBSCRIPT
sdOffice plugin objects can be extended with
custom VBScript functions placed in files associated with each object.
Automated File Distribution
The sdOffice
Network server provides support for file transfers
TO and
FROM
Office clients. In addition to streamlining the process of distributing
common versions of custom sdOffice or other script files, it provides a
simple mechanism for transferring ANY
file between systems with an installed
Office client.
Please
visit the
sdOffice 2 page on
our website for more information.
|