Friday, April 20, 2007

dsanden photo's

While looking for some art work for a presentation, I entered a search in Google images for "Mary Kay Building" and one of the photo's took me to this flickr site. There are some really amazing photo's, check it out here: dsanden photo's.

Wednesday, April 18, 2007

Mary Kay ART Strategy

Project Dragon Application Readiness Testing

Supply Chain Systems

©Mary Kay, Inc., 2007


Strategy

The Mary Kay strategy for application readiness testing (ART) is to create an environment which will be similar to the production environment for purposes of executing tests. In addition to the necessary hardware and software components expected of a production environment, the ART environment also has available tools that are essential to the testing process, such as load generation and issue resolution.

Prior to implementing any new systems, or critical components, in a production environment it is expected that they will first be observed in the ART environment. The observations of the systems under test allow for the development of profiles for each application that will be used for planning future environments. These profiles consist of resource requirements for the systems under test such as network (bandwidth and utilization), storage and servers.

Having the environment available allows Mary Kay to test performance, stability and configuration of the different infrastructure, applications, and systems that make up the Mary Kay Supply Chain. Beyond having the hardware and software resources available is only part of the equation. To complement the environment, Mary Kay has identified personnel resources that are subject matter experts in areas such as application, hardware, network and platform architectures, all of whom are can be made available to help facilitate testing and just as importantly, analyzing the results.


Test Areas

There are key focal areas that have been defined for volume testing prior to the Project Dragon go-live.

J.D. Edwards and DSI

First and foremost is the Mary Kay enterprise resource planning system, J.D. Edwards and its new warehousing functionality that will be leveraged in all international supply chain deployments. This area was chosen for the following reasons:

  1. Mary Kay is deploying a completely new version of JDE internationally, on an updated solution stack.

  2. The JDE Advance Warehouse modules are new functionality to both this version of JDE and to the Mary Kay supply chain.

  3. Mary Kay has made custom modifications to both JDE and DSI applications which need to be validated under load.

  4. The RF traffic generated by DSI from the China remote facility to the Shanghai data center needs to be tested to be within defined user requirements for response time.

Business Process

Mary Kay will be developing both telnet and web based scripts to drive load against core functional areas as defined by the Mary Kay business team.

  • Distribution

  • Procurement

  • Shop Floor Control

  • Sales Order

Application Integration

Both BizTalk and DSI are planning to use the same inbound services 1 for JDE. Identifying the capacity of the planned hardware resources is required to identify if and when scale out of the JDE inbound architecture will be needed.

Enterprise Application Integration

Application and partner integration are critical to the success of the Mary Kay supply chain. These areas have undergone both architectural and platform upgrades, as well as new development, for the Dragon implementation.

BizTalk Server 2006

A key area for test around the Mary Kay BizTalk implementation is the throughput performance of the direct bound architecture and validating the capacity of the planned hardware resources. In addition, Mary Kay has introduced new transport protocol that has yet to be tested under load.


3PL Web Services

Mary Kay has implemented a service oriented messaging gateway for integrating with third party logistic vendors. This architecture needs to be tested to validate that it will meet production capacities.


Supply Chain Services

Mary Kay has implemented several key services that provide support for internal processes which need to be tested under production loads.


Workload Models

A workload model represents the execution of automated scripts which drive a determined amount of load against one, or more systems based upon certain characteristics. Mary Kay has organized the suite of tests into several individual workloads. Each workload has the ability to be executed independently, or concurrently, with other workloads.

Executing all workloads ultimately makes up the “Day in the Life Of” workload which best models the daily processes and volumes of the Mary Kay supply chain.

  • Distribution

  • Procurement

  • Shop Floor Control

  • Sales Order

  • Region to Region Integration

  • 3PL Integration


Applications

J. D. Edwards

  • J.D. Edwards 8.11 SP1

  • 8.96_D1 Tools

  • IBM Java Runtime

  • IBM Web Sphere 6.0.2.13

  • Apache 2.0.47

  • Microsoft Windows Server 2003 Standard SP1 x86

  • Microsoft Sql Server 2005 Enterprise Edition x64 SP1

  • Microsoft Sql Server 2005 JDBC driver

Data Systems International (DSI)

  • DSI dcLink 5.0

  • Microsoft Windows Server 2003 Standard SP1 x86

  • Microsoft Sql Server 2005 Enterprise Edition x64 SP1

BizTalk Server

  • Microsoft BizTalk Server 2006

  • Microsoft Windows Server 2003 Standard SP1 x86

  • Microsoft Sql Server 2005 Enterprise Edition x64 SP1

  • Microsoft Enterprise Library 2.0

  • Microsoft .NET 2.0

3PL Services Tier

  • Microsoft Windows Server 2003 Standard SP1 x86

  • Microsoft Sql Server 2005 Enterprise Edition x64 SP1

  • Microsoft Enterprise Library 2.0

  • Microsoft .NET 2.0


Tools

Borland Silk Performer 2006

www.borland.com

Silk Performer is the tool that allows for creation of scripts that can be executed to emulate a number of users interacting with one, or more systems. Mary Kay has a license for up to 2500 concurrent virtual users (VU) and an unlimited number of development clients.

Shunra VE 5.0

www.shunra.com

Shunra is a network appliance that allows Mary Kay to simulate real world network conditions right in the lab, by introducing constraints such as available bandwidth, latency, packet loss and jitter. Using a device such as Shunra, Mary Kay will be able to accurately model production networks in China, such as the network between the remote facilities and the data center or the region to region networks such as Dallas to China, and the impact these networks will have on performance.

Identify AppSight for Microsoft Windows/.NET

www.identify.com

The AppSight application provides Mary Kay with the ability to quickly identify performance bottlenecks and assists with issue resolution.


1 All inbound transactions to JDE use the Xml Call object architecture


ART Testing

Wow...its hard to believe that I've been sequestered away in a small room with our Application Readiness Team (ART) for almost 8 weeks now!

I am currently responsible for the go-live readiness of our J.D. Edwards global implementation of standardized business processes ("Project Starburst"). In a nutshell, our business and technology teams have defined core business processes that will be executed in 4 regional data centers. We've significantly customized J.D. Edwards, DSI (RF scanning) and Integration. I need to know how these processes will execute to understand areas that will need to be tuned (code) or whether or not scale up/out is required and be able to present the results to my management team.

I hear you 'agilists' out there cringing...why wait until the middle of the implementation to discover the answer to these questions? That, my friends, is another story...

For now, this is just a follow up to a previous post: Mary Kay Labs and don't forget to check out Mary Kay ART Strategy.

Somehow I continue to get sucked into engagements like this...at Mary Kay, this is my 4th such engagement for Supply Chain. Hmm....again, another story...

To catch you up...

We have built a complete testing environment at Mary Kay to support activities such as this; the result of the hard work of several people (thanks, girls and guys!). This includes enough hardware to deploy our applications to production-size hardware. I won't bore you with the hardware specifications, but I can if you like! :) Just drop me a line...

We have a total of 37 scripts to date emulating a total of ~50 users (virtual) across 5 functional
areas for everything but integration. Thats a special beast unto itself...fortunately, we've had a lot of experience in this area!

Each script has had a specific data set staged for its execution. We have created enough data to support these 'day in the life of' activities. Each script was used to stage data for downstream activities, so the data was created using the application, not any 'tricks' (although we have a few of those).

Each script is written to stand alone and also to be scaled up as necessary. For example, I can have a single virtual user processing 100 'iterations' of Inbound Receive Case, or two users processing 50 'iterations', or 100 simultaneous users processing 1 iteration of Inbound Receive Case, all without changing the script or the data set.

This attention to detail when creating scripts is not required if you are have very fixed requirements. However, if you want to be able to scale up as necessary. e.g. lets scale up the number of users across each functional area until we find a breaking point (application or infrastructure) then it pays off in script re-usability.

Also, we have a number of administrative and configuration based scripts that aren't actually used during the load test. For example, we are running with a copy of our staging environments data. Our staging environment was configured by humans and not all of our finished good products have the same consistent configurations (e.g. unit of measure conversions, standard case sizes, expiration dates, etc..). When testing, your always better off with known data than unknown. So, we have a script that will go out and configure a particular part type (component, finished good) a particular way for consistency (again, using the application NOT direct manipulation). This is an asset from this engagement that can be handed back to the business team to assist with their daily tasks.

Oh, there is lots more where this came from but my brain has sufficiently cycled down for the night....see ya!

Debugging Windows Script Host VBScript

I just ran into this again today and I'm continually surprised by developers who don't know that you can debug VBScript using the Windows Script Debugger and more importantly Visual Studio 2003/2005 if its installed on the machine.

Next time you are writing a script and want to follow its execution throughout the entire lifecycle try typing the following at the command prompt:

cscript //X [scriptname].vbs

You will be prompted with a dialog asking what to do (depending on how the machine is configured for debugging and how many acceptable debuggers you have installed). Just follow the on-screen prompts.

Given that we automate a significant amount of tasks using VBScript, coupled with Windows Task Scheduler and Nant, being able to debug them is paramount to productivity.

Tuesday, April 17, 2007

Virtual PC 2007 on Vista Home Premium

As I alluded to in an earlier post, Virtual PC 2007 is not supported on Vista Home Premium (teach me to RTFM next time!).

That being said, I've been running it at home using VHD's created while at the office, for both Windows XP SP2 and Windows Server 2003 SP2 guests, without any problems. It seems to be as about as snappy an experience as I've had to date when playing with virtualization.

The VHD's were created under Virtual Server 2005 R2 using sysprep to establish a base OS image in a VHD that I can then copy, fire up, screw up, and delete as necessary.

I'm not sure I understand all the differences between using sysprep, or just copying an existing VHD and renaming, beyond the possible SID conflict you might experience with a server product like Sql, or BizTalk, and a domain controller. I've not had any problems using the copy-on-create method with a Sql VHD, and then renaming the newly created instance when it first boots; I've only run the default instance of Sql to date and have no idea what it might do with a named instance (or clustered!) but I believe that you could probably rename it by following the books online.

For prepping a BizTalk VHD, its important to not actually configure the server until its spun up for the first time and has been named appropriately.

Your mileage may vary...

I do notice that I have the virtualization option at the BIOS level with my new Dell workstation at home. I've not yet enabled it to see what difference it makes.

Monday, April 16, 2007

XAML Address Snippet

Testing to see how the XAML code formats.  I've not had much consistent luck formatting and displaying any sort of code on this blog. It always seems to want to scrunch everything
into a much smaller area that what should be available.
Looks like I'm also changing my blog style template so that I can suitably post code if I like.  I've intentionally left it out because it formats so badly using my old style sheet.
I'd like to see about possibly creating a custom control around the XAML below; see what that takes in WPF.  I know that when building an app, there needs to be a certain symmetry
to the layout and the positioning of controls.. the address input always seemed to be a natural candidate for a custom control...maybe its too easy to just slap together all of the
appropriate labels and text boxes to make it worthwhile. It'll be interesting regardless.
Here is a sample of what the component would look like:



Here is the XAML to produce the 'address':
<GroupBox BorderThickness="1" Width="Auto" Margin="10,10,10,10" Background="AliceBlue">
<GroupBox.Header>
<Label>Address Information</Label>
</GroupBox.Header>

<Grid Name="Address1" Grid.Column="0" Margin="10,10,6,10" HorizontalAlignment="Left" Height="Auto">
<Grid.Resources>
<Style TargetType ="{x:Type TextBox}">
<Setter Property="Margin" Value="4,4,4,4"/>
<Setter Property="HorizontalAlignment" Value="Left"/>
</Style>
<Style TargetType="{x:Type Label}">
<Setter Property ="Margin" Value="4,4,4,4"/>
<Setter Property ="VerticalAlignment" Value="Top"/>
</Style>

<Style TargetType="{x:Type RowDefinition}">
<Setter Property ="Height" Value="Auto"/>
</Style>

</Grid.Resources>

<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
</Grid.ColumnDefinitions>

<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition/>
<RowDefinition/>
<RowDefinition/>
<RowDefinition/>
</Grid.RowDefinitions>

<Label Grid.Column="0" Grid.Row="0" Content="Address Line 1" />
<Label Grid.Column="0" Grid.Row="1" Content="Address Line 2" />
<Label Grid.Column="0" Grid.Row="2" Content="Address Line 3" />
<Label Grid.Column="0" Grid.Row="3" Content="City" />
<Label Grid.Column="3" Grid.Row="3" Content="State" />
<Label Grid.Column="5" Grid.Row="3" Content="Zip" />


<TextBox Grid.Column="1" Grid.Row="0" Grid.ColumnSpan="4" Text="Address Line 1" Width="200" />
<TextBox Grid.Column="1" Grid.Row="1" Grid.ColumnSpan="4" Text="Address Line 2" Width="200" />
<TextBox Grid.Column="1" Grid.Row="2" Grid.ColumnSpan="4" Text="Address Line 3" Width="200" />
<TextBox Grid.Column="1" Grid.Row="3" Grid.ColumnSpan="2" Text="City" Width="100" />
<ComboBox Grid.Column="4" Grid.Row="3" Width="Auto" SelectedIndex="0" Height="28">

<ComboBoxItem>AL</ComboBoxItem>
<ComboBoxItem>AR</ComboBoxItem>
<ComboBoxItem>OK</ComboBoxItem>
<ComboBoxItem>TX</ComboBoxItem>

</ComboBox>
<TextBox Grid.Column="6" Grid.Row="3" Text="Zip" Width="100" />
</Grid>

</GroupBox>