The company has a Purchase Order Management application suite which is several releases old. This application suite has few client applications built over Microsoft .NET coupled with legacy systems like Mainframes and RS6000 for Retail shops to place orders from their retail outlets.
Our team proposed new application architecture to cater to the needs of the PO Systems, as there were several challenges with upgrading the application, i.e., any change one of the modules in the application involved end-to-end changes in all the layers of the application. The new architecture of the application is based on .NET 3.5, WCF, BizTalk, SharePoint, SQL Server 2008 BI Stack. Now let us discuss about the role of Microsoft BI stack in this engagement.
Scenario:-
As per the existing application architecture, the retail shops and merchandising agents have the flexibility to either fill out a worksheet using a thick client application and transmit them to the server, where the purchase orders are created and moved to the Mainframes, or, the retail shops could place their orders via the merchandising agents, in which case, there were two workflows, one being the Merchandising Agents using the application to fill out a form to generate a PO or, create the PO on the Mainframe. So these two types of the purchase orders are categorized as to Application generated and non application generated purchase orders.
Worksheets are created using the Client Application is stored in the form of an XML document in the SQL Server 2000 (Client Application) and DB2 (Mainframe and RS6000) databases.
Here’s the block diagram that shows the current workflow of Purchase Order (PO) Processing,
Objective:-
The scope of this engagement is widespread, and there are several teams working different modules of the engagement.
Here are few of the modules that we were involved in,
- Conversion from SQL Server 2000 MSDE to SQL Express 2008 for Client Applications.
- Implement Integrated Windows Authentication on the Client Application.
- Generate Statistics and Audit Reports for Application/Feature usage.
This task looks simple though but posted a numerous issues at the time of implementation, here are the few of the tasks that were carried out for the same,
- Silent installation script to install SQL Express 2008 pre requisites and resume installation on system restart.
- Silent installation batch script to install SQL Express 2008 with a named instance.
Implement Integrated Windows Authentication on the Client Application
Implementing integrated windows authentication was rather simple task. We had to create one LDAP group for the Retail shops/Merchandising Agents and one LDAP group for the administrative users and attach them to the corresponding roles to have data entry or administrative permissions. Thanks to Credential caching feature of Windows, this ensures integrated windows authentication on SQL Express 2008 even in a disconnected mode.
Generate Statistics and Audit Reports for Application/Feature usage
The Statistics and Audit Reports for Application usage is one of the major tasks that we were involved in. There are 3 different reports,
- A report to determine how many retail shops are using the client application. The selection criteria for this report is flexible to produce the result based on different combinations of divisions (for ex, apparels, home goods, etc), departments (ex, winter wear, men’s footwear, accessories, etc), retail shop and worksheet transmitter, this is also called the productivity report.
- A report that tells how many PO’s were created for individual departments also called as master report, with the division as selection criteria.
- An audit report that provides the audit information regarding use of the Lead Time Calculation (LTC) logic, that suggests optimal shipping dates, within the client application, in order to assess the level of use as well as the amount of manual adjustment that is performed after the logic has been applied in the client application. The weekly report illustrates by user the methods by which ship date and ladder plan information was supplied to the client application.
To generate these reports we have used SQL Server Integration Services (SSIS) as ETL tool and SQL Server Reporting Services (SSRS) for the reporting, coupled with ASP.NET 2.0 Website to host the reports and provide selection criteria.
The SSIS packages fetches PO’s from various data sources such as the SQL Server 2000 databases, Mainframe and RS6000 DB2 databases and as per the new architecture of the system, the master data will also be available in a SQL Server 2008 databases. But since there are divisions which are still running on the older version of the application suite, it is necessary to keep the data from the older system as is and provide a switch for the package to start fetching data from SQL Server 2008 databases when all of the divisions are migrated to new version.
The productivity report and the master report are straight forward. These reports count the number of PO’s generated using client application, Mainframes, and RS6000. After getting the count of PO’s these are then stored in the corresponding tables for the reports.
The audit report requires to read through the worksheet and PO XML documents stored in the database to check whether the LTC logic was used or not. SQL Server provides us with XQuery language, using which we can query xml data type. XQuery handles both typed and untyped data. After reading through the XML documents, the values of the required fields are stored in a table. This table contains all the line items of the worksheet, in which the LTC logic was switched on/off.
Apart from these reports there are other BI requirements in this application suite which are planned, for example, analyzing quarterly sales results and forecasting revenues, using SQL Server Analysis Service. Soon we will have more updates on this blog, with more data related to Microsoft BI technologies used in this engagement.
