Seun Daniels -- daniels_seun@yahoo.com -- is a Nigerian scam artist.

Tiffany Wallace -- tiffanywallace2444 -- is a Nigerian scam artist.
Leading factors:
Improper grammar within simple sentences:
"I was born and raised in the State, I was born and raised up there, and i received my Bachelor's Degree at University of Virginia and i'm so much into Art's and Designs.."
Poorly translated conjunctions/word combinations:
"she fell from the stairs of a sky rise and has a severe pelvic dislocation..."
Failure to use punctuation, even in sentences where the need is clear:
"Like I said i would really love to know more..."
Failure to capitalize letters within sentences, yet always capitalizes first letter:
"Like I said i would really love to know more..."
Unbelievable circumstances:
"she fell from the stairs of a sky rise and has a severe pelvic dislocation..."
Change of tense/word form within sentences:
"I am currently staying with her down in Nigeria and I have been there for two weeks now and I would be returning back to the State soon."
Currently living/visiting Nigerian location:
(See above statement)
Improper word usage: Uses "the State" instead of the name of the state.

He/she will usually send a form letter containing the following key phrases:
"Recently I got a message from my Mom's doctor in Nigeria that she's very sick"
"fell from the stairs of a sky rise"
"severe pelvic dislocation"

Custom CRM Workflow Activities/Steps And Project Versioning

By now, many of you who have tried to make use of structured development methodologies in the development of CRM 4.0 custom workflow activities, have discovered that CRM 4.0's implementation of the Windows Workflow Foundation as its workflow system is a hindrance to you. You' aren't alone.

It appears that midstream, Microsoft wanted to turn the CRM product line into one of their "Live" applications. That would have been a nice touch, but the existing design does not adequately support that implementation unless you are happy with limiting yourself to the very small number and featureless out-of-the-box workflow steps available to you. Many of us are not, and that's where CRM's lack of staged development support can grind your efforts to a halt if you are not careful.

Contributing Factors

If you have taken it upon yourself to modify or extend the base functionality of your CRM 4.0 implementation, version each build of your project, are working within an environment which makes use of staged development, and are developing custom workflow activities, you need to prepare yourself for what lies ahead. Staged development of applications is a good practice, and in many large organizations with a strict quality program, its required. Versioning each build is also a good practice and required by many organizations. So why is it that Microsoft thinks we should develop directly on the production servers?

The Cause

Custom workflow activities have their version number embedded within the definition of the step when added to a workflow. The system makes use of this version number and the type name to locate the custom step at runtime. By adding custom activities to a workflow, you are in effect restricting your workflow to use only specific versions of activities. When you consider that differing versions of custom activities could cause you problems, this seems like a reasonable restriction. However, if the version number of your custom activities are changing with each build, even when there are no changes to the custom activities themselves, you end up invalidating all workflows you created previously. The only way to get such workflows working under the new version, is to remove and replace all custom activities with the newer versions.

If you fail to replace these activities, you will receive one of CRM's useless errors that an fault occurred while attempting to publish the workflow, and that you should attempt the publish action again. Do so only if you have time to waste. It's not like the server is going to change its mind, decide to stop playing foolish games with you, and suddenly allow you to publish the workflow. Also, don't waste your time attempting to debug your code, because the issue isn't there. In your trace logs, you will find an exception which states something like "Crm Exception: Message: Could not find a plugin using assembly name and type, ErrorCode: -2147200995". The exception leaves out a very vital condition of the type resolution process. The true cause of the error, which is that the plugin/activity could not be found using the given name, type and version.

What Microsoft Should Have Done To Avoid Workflow Development Issues

Okay, so take all of this with a grain of salt. How I feel Microsoft should have built the workflow system is based on MY many years of experience with a dedication to strong 0bject-oriented methodologies, a high level of efficiency, ease of use, reliability, and dynamic/flexible operation. You may share some of my views with the same enthusiasm while considering me "totally off my rocker" on others. My reason for this posting is to provide you (and Microsoft) with thoughts to ponder in overcoming any workflow system issues you may be having.

Is the Windows Workflow Foundation built in an object-oriented (OO) manner? Yes. Is CRM's implementation of an OO nature? Yes. The problems I see are not that they avoided OO practices, but that their implementation is on a very weak and problematic OO design. I do not feel that the manner in which CRM 4.0 implements the WWF is worth the time Microsoft has committed to its development, nor do I feel that the overall design of the WWF is what it needs to be in order to support the widest possible (and reasonable) range of applications, environments and implementations.

Is the execution of CRM's workflow system efficient? No, not at all. In fact, on a scale of 1 to 10, I personally give it a -10 -- but then I can be pretty picky here. Even with the use of reflection in some areas of my own workflow system designs (past and present) to facilitate a wide level of flexibility, I am able to execute workflow processes with a far greater number of features, and with way more error-handling and loggging support, in a fraction of the time that CRM currently requires. In some cases, I've found workflows within my current system to execute more than 2000 times faster than a closely similar implementation in CRM. In systems with a high transaction count, processes such as this need to be as efficient as possible, and I find that CRM 4.0 falls short.

Another issue regarding the manner in which workflows are managed, is that Microsoft has chosen to compile and cache them to disk.  The claim is that it is more efficient to do this.  I have found that this only adds further problems, because the management of those cached resources is managed poorly.  You might imagine as I did, that upon publishing a workflow, the cached copy would be invalidated so as to begin making use of the new version.  This is not the case.  I have seen cases in which an edited workflow is not put into use by the system for almost an hour!  Is it efficient to leave workflows in place for up to an hour which are known by the developer to be faulty?

Is the CRM workflow system easy to use? If you are using the out-of-the-box UI and provided components, it does seem to be fairly easy to develop simple workflows. Unfortunately, all of that is lost the moment that your developers must begin developing custom activities of a moderate to complex nature. This is due primarily to the rigid nature in which activities handle input parameters, the limited support of the CRM service instance provided within the workflow context object, and the manner in which the system locates and executes activity objects. Sadly, to overcome these issues, the system needs to be revamped from the ground up to support a more flexible model of workflow definition and execution. For example, instead of representing activities as strongly typed objects during the design and development phases, they should be represented by a base object which supports dynamic management of parameters, conditions, and child steps, each which support expression-based values. Such a design would allow for workflow development on systems without the installation of CRM, the Windows Workflow Foundations system, or associated activity libraries. It would also allow for a more efficient process of workflow modification in systems requiring constant availability.

Consider how activity data is recorded to disk via CRM's export process. Although the workflow header (if you will) is represented by XML, the activities (aka "steps") are represented by unreadable serialized binary data. In my design, the entire content of a workflow is in human-readable XML format, with a step being nothing more than an element describing the type of the object to instantiate at runtime, and child collection elements housing the parameters, conditions and child steps. By supporting a dynamic format, we greatly improve ease of use at all levels (design, development, operation/execution, etc.) by providing additional avenues through which to edit and build upon existing structures.

In the sample below, you can see how a step specifies the assembly and type of an object to create. Don't want to point to a specific version? Simply remove the portions of the assembly reference which are too rigid. I even go to the point of supporting file locations from which to load an assembly and its debug symbols if provided instead of an assembly name. Conditions are simple statements which support expression-based values through the use of an inline data element "slug" resolver. Parameters are simple elements which also support expression-based values. Want to add parameters? Simply add them to the XML-based workflow definition file. Because they are read in and handled dynamically, there's no need to worry with delegates which allow typographical errors, or activity upgrades invalidating your workflow. In fact, such a flexible design actually allows your activities to support internally managed versioning (determination of intended operation based on a supplied version number of format of input parameters) if you wish. (The full design of my workflow definition file format supports far more features than shown here, but the following sample should be sufficient to illustrate the simplicity which one might expect to be present in CRM's workflow export.)

<Workflow Description="A sample workflow" Name="Sample Workflow">
    <Steps>
        <Step Type="ConditionStep" Description="Determine if we should do anything.">
            <Conditions>
                <Condition LeftArgument="{#PrimaryEntity.Amount}" Operator="GreaterThanOrEqual" RightArgument="100.00" />
            </Conditions>
            <Steps>
                <Step Type="EmailStep">
                    <Parameters>
                        <Parameter Name="From">{#PrimaryEntity.createdby}</Parameter>
                        <Parameter Name="To">{#PrimaryEntity.Assignee</Parameter>
                        <Parameter Name="Template">Sample email template</Parameter>
                    </Parameters>
                </Step>
            </Steps>
        </Step>
    </Steps>
</Workflow>

Now let's pull all of these points together by speaking to the reliability of the CRM workflow system. The more you deal with the CRM workflow system and its associated components, the more you may begin to wonder if any testing was performed on the product prior to its release. At the base of any good workflow system, you should find a powerful resolver object/process which provides support for values based upon data expressions. These are commonly referred to as inline data element resolvers. CRM has one, which they call the "data slug resolver", and is responsible for resolving the content of templates (such as email templates) and workflow activity forms in a dynamic manner. I've spoken to Microsoft about the majority of the issues I've found which relate to CRM's resolver. These include the fact that it does not appear to follow any standard convention in describing values, is extrememly limiting in access to objects and properties, injects spacing which was not present in the templates, and is frankly too riddled with bugs to be relied upon. Their response was that they have seen and agree to all of those points, and that development continues to move forward. Quite a few times now, comments have been made which cause me to believe that we should just wait for CRM 5.0. Not having the time to wait, I built one to replace it (hence the difference of "{#" instead of "{!" in data elements within my sample) in three weeks which is very stable, makes use of standard dot notation, and is far more robust than theirs. If you are making use of a large number of templates and/or need them to be more precise in the generation of their content, you'll probably need to take on the similar task of building a replacement resolver. In short, the reliability is just not there, nor do I believe it wise to expect it to appear anytime soon.

Possible Workarounds

As with most problems encountered there are multiple ways to get around them, but before settling on one, take time to consider the requirements of your organization/department.

1. Turn off versioning for plugins. When I brought the issue of activity versioning to Microsoft's attention, they agreed that they had never really considered how build versioning might affect the process. Their own developers stated that they would suggest we create a proxy class whose version never changes. You could do that, and it would work if all your changes were limited to the logic within the Execute method, but what if you need to modify the parameter list or add additional custom activities? Well, now you are changing the proxy, and since its not versioned, you open yourself up to other issues (including possible dismissal from strict contracts which require total software auditing capabilities).

2. Late-bind your objects via a proxy. This makes use of Microsoft's idea of building a proxy project through which your plugins are called, yet applies a level of slightly complex intelligence which could possibly make the process work a little better. In this concept, your proxy calls upon a configuration file or configuration settings to locate, instantiate and return activities based on full names of types and a reference to their file location if not currently loaded into the application domain. The problem with this concept, is that it still does not overcome the blocking issue regarding changing parameters or the addition of new custom activities which would change the version of the proxy. It will cut down on the frequency in which you have to update workflows due to version number differences alone, but will not prevent you from having to make modifications after adding/modifying custom steps.

3. Replace the entire workflow execution process with your own. Honestly, this is the only solution that works to resolve the issue in its entirety, but unless you have experience in developing such as system, I wouldn't suggest taking on the task. I've built such systems, which are truly dynamic in nature and support build versioning and such, so we opted to go this route and commit about 4 weeks of my time to the task, but consider #4 before committing resources to workflow system design and development.

4. Build a process to simplify workflow reconstruction. This concept will allow you the flexibility of continuing workflow development, continuing activity development, and rebuilding workflows within an instant. Our problems required a more robust workflow system overall, which is why we decided to take on efforts of building a replacement workflow system, but in most cases, an automated workflow reconstruction process will be sufficient. I'll explain what is needed.

Automated Workflow Reconstruction

The idea of automated workflow reconstruction came to me quite some time ago, but since it would not resolve ALL of our roadblocks, it was dismissed for a complete workflow system replacement. If the versioning issue is the only one you have, and you cannot get around the versioning problem any other way, then by all means consider this idea. In general, you will need to build a process which reads in an existing workflow definition from the CRM system, replaces steps with your most recent versions, saves the changes, and publishes the workflow back to the system. Here's some things you will need to consider in your implementation:

1. Workflow versioning. It would not be cool to entirely lose your existing workflows due to a bug in your reconstruction process. I would suggest that you work in a version number at the end of your workflow titles, and create modified copies of workflows instead of editing and attempting to replace the current one in operation.

2. Workflow deconstruction. This processs will need to read in a workflow from the CRM system and deserialize the step data. Although a workflow is primarily a logical representation of subprocesses to execute, Microsoft chose to "compile" and hide the design of the steps by serializing the step collection and storing it in a property called uidata (user interface data). The more reasonable handling of this (given my above design for flexibility) would be to store the steps as XML.

3. Step update/replacements. After deconstructing/deserializing the activities of the workflow, you will need to go through each custom step (skipping the base steps) and ensure that it is making use of the version you will have present on your server. I would suggest a comparison of the type, name and version values, since this is how CRM looks for activity objects as well. If the step differs, your update efforts will need to check for editing/replacing the parameter definitions of the step.

4. Workflow construction. Like the deconstruction process which deserialized the steps, this step of your workflow reconstruction process will need to serialize the new step collection and place it back into the uidata property.

5. Save and publish. Once you have completed the reconstruction of the workflow and its steps, you need to save the workflow back to the system. The best manner of doing so (in light of item #1), would be to create an all new workflow with a versioned name, save the workflow definition/design to CRM, and publish the new version. If successful, you will want to immediately unpublish the previous version. Unpublishing the workflow will put it into a "Draft" state, leaving it available for you to roll back to if possible, yet causing the system to ignore its presence.

In closing...

I realize that this post does not provide you with a quick fix to your problems regarding the versioning of workflow activities. If I provided the code for all of my ideas, and explained the reasons for each action, this post would become a novel. My goal is to explain issues regarding custom activity versioning issues, the design flaws of CRM's workflow system, and some of the options you may wish to consider in overcoming them. Take time to consider which actions are most beneficial for your organization and the limitations and best practice requirements applicable to you, before setting off on your chosen course. If you are facing multiple roadblocks as I was, you may want to consider a third-party replacement product or developing your own replacement workflow process. How you go about developing or implementing such a replacement process will certainly depend on the issues you need to overcome. Good luck in your endeavors!

NOTE: The USDA currently owns the rights to my most recent workflow system. Please understand and honor the fact that unless I receive documentation from them permitting me to share its coding with others, I cannot do so.

Eric Bewley, Sr. Software Consultant

USDA/NRCS, Vistronix

Don't Buy Walmart Visa Debit Cards!!!

DON'T BUY WAL*MART VISA GIFT CARDS!!!

From time to time I encounter a scam that, as a military citizen who has sworn to protect my fellow citizens, I feel is a duty of mine to warn others about. The latest scam I have encountered, is the Walmart Visa debit card, also known as a Walmart Visa Gift Card.

First of all, dear old Sam Walton is undoubtedly rolling over in his grave with all the damage that has been done to the Walmart business he created. What was once a business which only sold products made in the USA and the rare items for which there were no US manufacturers of similar products, much of the contents of the stores are now from foreign countries.

What's worse, is that much of the customer service support, such as for the Visa debit cards, has been farmed out to organizations in foreign countries as well. The biggest problem with this is that there are no enforceable contractual agreements across national borders. Many don't realize that giving their personal information out to such persons, places them at a MUCH higher level of risk of identity theft. Think about it. If a person in a foreign land steals your identity due to access to your account(s), you cannot call the police on them and you cannot take them to court. Are these the people that you want to grant access to your personal accounts?

The other issue with the debit/gift cards sold by Walmart, is that there are a lot of charges that, although not necessarily hidden from you, will bite you in the butt -- repeatedly.

First of all, there's the $5.44 fee you will pay to purchase the card. That isn't printed on the face of the packaging for the card. All you'll see is "$100 Gift Value". When you open the sealed packaging, you'll find an insert that tells you about the fees you were previously unaware of.

Next, are the fees that are charged when converting the card to a reloadable form. Bear in mind that it will not only cost you $5 to do so, but will also cost you another $4.94 PER MONTH for it to be in reloadable form!

To compound the problem, you will be charged a minimum of $0.50 per call to customer service, and if you ask them for a refund, that too will cost you another $5.00. They tell you in the 'fine print' insert that you can obtain a full refund, but ONLY if there have been no transactions against the card. That's where they get you again.

I bought my Walmart Visa Gift Card to use with Yahoo Music, so that I could better protect myself against fraudulent charges. (That's another story in which Bank of America is at fault.) I thought that if someone was able to steal this card's information, that there would be a limit to the damage they could do to my account. Not true, because all account information for the debit cards is sent to the Philippines. I made two attempts to have Yahoo use the new card for my unlimited music subscription. They attempt to bill $1 to your card, in order to test for the validity of the information provided. Yahoo was told that the charge was refused/rejected, yet the $1 charge was charged to the card anyway. Since these charges appear on the account, I am refused a full refund although the card refuses to function.

If you need a Visa card that you can load and use without having to worry about charges for insufficient funds charges, or which cannot drain your checking/savings account of all available funds, I suggest you speak with your banking organization about a secured Visa credit card. If your current banking institution doesn't/won't provide you with one, and many don't, continue inquiring with other banks in your area. Someone is bound to issue you a secured credit card (that's one in which you provide the funds for upfront) without charging you all the fees that Walmart will charge you.

Following is Walmart's response to my complaint about the issue. Notice that they clearly state that they have no access to the information and that the only method to address the issue is to call someone else on the phone. Bear in mind that they charge you for each call you make.

How Public Is YOUR W2?

As many of you know, some companies work really hard to get your tax documents out to you in a timely manner. Others don't really care HOW the information gets to you, as long as they aren't held to blame for missing the deadlines set forth by government agencies. Some of those who offload the work of tax document generation to a third party, may be publicizing that information on the Internet!!!

I needed to obtain a W2 from a previous employer who states that they mailed out all tax documents before the deadline. It's lost in the mail. Yeah, no big surprise there. Instead of agreeing to send it out to me again, I was given the address to a public Internet site (www.downloadmyform.com) to download the form myself. Personal information security is a concern of mine -- in fact, it's part of my job -- so I thought I'd give it a whirl and take a look at the security processes involved. As it turns out, all anyone would need in order to download my W2 from this site are my last name, Social Security number and the public acronym of the company I used to work for. Yep -- that was it!

I went to a coworker of mine and tasked him with bringing up my W2 via the site. It took him less than 45 seconds to do so, because as a developer he happens to have access to the company databases.

Perhaps you are asking yourself, "Who would have my Social Security Number?" Well, that would be the majority of all organizations you do business with who have an interest of some sort in your credit rating or believes that Social Security numbers are good for uniquely identifying you from everyone else in the country/world. Now consider the number of companies who have sent (or are sending) a large amount of their customer service and/or database management support overseas, and the number of hackers on the web who would LOVE to get copies of such documents or yours and sell them to counterfeiters. The numbers are VERY high and I'd suggest you dial 911 and report a heart attack prior to researching the operating standards of the companies you do business with.

Currently, I and my software developers are working on a project which will make a lot of these concerns go away, but until we are ready to release that application, I suggest you contact each of the companies you have worked with in recent years and ensure that they have not made your personal tax information available on the Internet. If they HAVE made any of your information available on the web, politely ask them to remove it immediately and inform them that they DO NOT have your permission to ever perform such an act of stupidity with your information ever again. Next, you should bow your head, cover yourself in ashes, kneel in an Easterly direction, sacrifice a small animal or whatever it is you prefer to do while praying that you plugged the leak before the hackers of the world gained access to it.