This is a sample configuration store that I wrote for a SharePoint implementation that I was working on. The configuration manager has a simple interface that takes two keys (siteID, and Key)  and returns the string associated with these keys here is the interface definition

The implementation for the IConfiguration manager expects to find the list URL and the site URL where the list exists(the list can exist in any site) in the application settings of the web.config. The implementation caches the retrieved values which has its own draw backs as changes to the list are not reflected till the cash expires but for this implementation the requirement did not expect lots of changes.

The Provider just loads the implementation based on the class name and assembly name of an entry in the application settings in web.config.

The consumer would write code similar to

      IConfigurationManager cm = ConfigurationManagerProvider.GetConfigurationManager();

      lblSiteTitle.Text = cm.GetConfiguration("Site1", "Key1");

 View it all at  www.moustafarefaat.com/MoustafaPWS/custome_adapters.aspx Thanks

1. On the  ItemStyle.xsl, I have added a new custom style for my anything slider

2. And I modified the  ContentQueryMain.xsl main loop to contain a choose and in case it is “AnyThingCustomStyle” it uses a different template than the one used with the default templates

It turns out this is the reason is McAfee virus Scan blocks mass mailing worms. To correct this:

1. A library class that contains the RawString class and Part class to make it easy to set the type of the message
2. A BTS project that contain a pipeline to use for sending the email.
3. A simple orchestration that accepts a simple file schema and just sends the email. The input file in this example is empty it is just used to fire the orchestration.

Read more..

In this article I will explain how to use MS SQL Management Objects (SMO) to create a MS SQL database from C# code. In this sample will

1. Enumerate all the SQL servers in the network and fill a list box where the user can select one of the servers.
2. The user will enter the Database Name to create.
3. The user will enter an AD account to grant right to.
4. When the user click "Create Database" the system will check for the existence of the database.

Read More..

Mastering The BizTalk Technical Interview

Wisdom is learning all we can, but having the humility to realize that we do not know it all. Mastering the BizTalk Technical Interview 200 BizTalk Technical questions with clear and concise answers will help you gain more wisdom in BizTalk Interviews. The difference between a great BizTalk developer and someone who kind of knows some stuff is how you answer the BizTalk Interview questions in a way that will show how knowledgeable you are. The 200 questions I have assembled are for: job seekers (junior/senior developers, architects, team/technical leads), and interviewers. BizTalk Technical Interview Questions covers BizTalk versions 2002, 2004, 2006, 2006R and 2006 RFID. The questions cover the following areas:

• Basic Questions.
• General Questions.
• Schema Design Questions.
• Pipelines and Pipeline components Questions.
• Maps Questions.
• Messaging Questions.
• Adapters and Accelerators Questions.
• Orchestrations Questions.
• Rules Engine Questions.
• BAM and BAS Questions.
• Deployment and Installation Questions.

Learn the fundamentals relating to BizTalk and Enterprise Application Integration in an easy to understand questions and answers approach. It covers 200 realistic interview Questions with answers that will impress your interviewer. A quick reference guide, a refresher and a roadmap covering a wide range of BizTalk and EAI related topics and interview tips.  Read More..

Hope this helps

 A very common network setup for security is creating a perimeter network or DMZ that “outsiders” can access, but the DMZ is separated by a firewall from the secure internal network. Additionally there might be another firewall inside the secure network separating the database servers.

Because the infrastructure is split into multiple zones, you have to have the same splits in your application architecture to make it possible to deploy on the infrastructure. This also has the related issues of communications across the zones, passing identities, etc. So in more details you have to:

• Design the architecture to include a cleanly separated business API to ensure there is a distinct business tier.
• Split the business tier into two parts, creating an “interface” tier and an “implementation” tier.
• The interface tier is responsible for handling boundary activities such as validation and authentication, while the implementation tier holds the main business logic. This boundary verification logic enhances the security before passing the request to the secure network, beyond what could be done using a firewall alone.
• The service interface tier gets deployed into the DMZ, and the implementation tier into the secure network.
• Just one last note, does not that look like the Façade Pattern? Well close, but not the same. Hope this helps you with your system challenges.

• There are issues with determining who gets notified of errors, is it always the user?
• Security people are quick to point out that error messages can include information that could be used for compromising the system. The classic example being “connection string X failed” and the connection string contains the database username and password.
• System administrators need to know when problems are happening, but do they need to know about every error? Error reporting to the system administrator can actually be very complex because it could be a group of system administrators or even include the business owners of the application. So there might be a whole workflow to how errors get reported to the people who own and maintain the application.
• How should errors be propagated within the architecture? Are errors always handled at the closest point to where they occur, or use some kind of global exception handling?

• Categorizing errors as “business” versus “technical” errors is necessary to support sophisticated exception management.
• Sometimes exceptions are not necessarily errors, but are expected and the business logic takes an alternate successful path, and so in those cases the exception can be handled locally in the code where they occur. Otherwise exceptions are propagated up until it reaches the system boundary where a global exception handler reacts to the exception.
• The propagation is done using normal .NET try/catch/throw exception handling. Developers sometimes think about using error codes because of older C style conventions or concern over performance of .NET exception handling, but performance for failed requests typically isn’t an issue.
• Business exceptions get raised by the business logic when errors such as a business rule violation or validation error occurs. Business exceptions are also always raised with a safe and user acceptable message.
• At the system boundary in the global exception handler, all technical exceptions should be logged for the system administrator and include a unique log id. The message returned to the user should be replaced with a generic error message so unsafe information does not get leaked out of the system. But the generic error message must include the unique log id entry, so if the user contacts the system administrator for help, then the administrator can determine the actual technical error message by looking up the log entry using the unique id. This saves time and prevents the system administrator from having to ask the user what time the error happened, can they reproduce the error again, etc. 

• This problem often shows up simply because it isn’t a requirement when a new application is built. Naturally a new application might depend on other existing applications and so needs to call out into them, but typically a new application does not initially have some other application that is dependent on the new one and needs to call into it. So because it isn’t a requirement, the architecture design does not include support for it.
• However, in large organizations there really are only a small percentage of applications that go through their entire lifecycle without at some point needing to be integrated with other applications. So this requirement always seems to come up sometime after your new application is deployed. So you could at that point modify the architecture of your application to support being integrated with, but often that is unlikely to happen because the new requirement is coming from a need in another application, and there is no budget or permission at that time to significantly modify your application to support the needs of the other application.
•  The classic solutions in these cases are to try integrating either through screen scraping or data integration, but both techniques are awkward, expensive, and difficult to maintain and so customers normally want to avoid those approaches if possible.

• Ensure that there is an explicit business tier with a cleanly separated API.
• Ensuring the business tier is exposed by some technology that can be accessed by external systems is necessary.
• Include an interception mechanism that can raise business events after certain things occur. Sometimes external systems might need to know when things are occurring in your system, and providing business events makes it possible to support that without requiring that external systems to poll your system through the business API.
• Use a pub/sub mechanism with the business events. This way, systems can be added or removed which respond to the business events without your application needing to know. If they were calling into your business API, the performance impacts might be enough that you need to be aware of that usage, but a business event doesn’t affect your system based on how it is used.