ASP.Net Web API – Part 1

Companies such as Google, Facebook, Twitter, SalesForce, Netflix have exposed technological solutions to public. Central part of this success is API. Significant amount of traffic comes through API’s. Today API’s are a mainstream and is a business transformation strategy in most organizations.

Let us take a step back and see how it evolved. Application Programming Interfaces (API) are not new in the technology world. Traditionally we had been doing SOA using ASP.Net Web Services with .Net 1.1 and graduated to WCF with .Net Framework 2.0 onwards, middleware technologies like BizTalk to connect to Line-Of-Business applications and commercial ESB’s. Following the tenets of SOA and exposing business layer as services led to application architectures decoupled. Presentation layer can be changed with changing frontend technologies and user experience without having to re-develop the business layer. Layered architectures and API’s exposed through services protected the investment. API’s were also an extension of the product and this provisioned for other applications to interact with it. Service API’s can be consumed with many clients of different technologies.  Challenge was solved through making those services interoperable.

Technologies like WCF mostly relied on Xml data contracts and SOAP protocols for interoperability.  This addressed the issue in enterprise world. Meanwhile, in the consumer world, with the mobility disruption, applications powered by backend services demanded to consume those services in an efficient way. Xml and SOAP protocols are not an efficient way of communication. SOAP protocol is built on top of HTTP and adds a lot of redundancy. Most of the mobile applications may not need all of the SOAP features. Xml is not an efficient form of data representation especially for a mobile clients with limited connectivity, bandwidth and processing power. Elsewhere in the world, while technologists arguing on SOAP v/s REST and Xml v/s JSON. REST and JSON seemed to be a perfect fit for consumer oriented API’s. Compared to Xml, JSON is efficient and interoperable way to represent data. REST removes the overhead of communication and simplifies by representing the asset in the form of Http Verbs (Get, PUT, POST, DELETE and others).

I would not get into REST v/s SOAP debate. One size may not fit all. Each one was designed to solve specific problems. On a broad classification, API’s can be classified as RPC API and Resource based API. RPC API allows clients to consume data and invoke remote procedural calls on server. For eg: Get Customer Detail, Send Notification, Process Data. Whereas, Resource based API is geared towards consuming and manipulating resources. Eg: Add Customer, Get Orders, Update Inventory.

REST is extremely pleasing. Developing RESTstyle services following all the constraints in the real world pushes limits. Clients that consume REST services may become chatty. A single screen display may require calls to several services. There are ways to solve this by supporting MIME requests and wrapping up several calls into one request and API styles. Sometimes you may need to design services as pragmatic REST.  However, for public API’s REST or HTTP (pragmatic REST) services makes more sense.

Today within a Microsoft technology stack, there are two choices, WCF and ASP.Net Web API frameworks for developers to develop RESTstyle services. WCF was originally created for RPC style SOAP based calls and later extensions were added to framework to support REST. REST does not have a first class support in WCF in terms of programming model and hosting capabilities. ASP.Net WEB API address these concerns and take the platform to next level.

ASP.Net Web API is an application framework for developing HTTP services. Remember, ASP.Net Web API is not REST. REST is an architecture style with a set of constraints. ASP.Net Web API lets you develop RESTstyle services.  Here you can find more information on ASP.Net Web API to get you started.

Conclusion

The post was to brief on API evolution, need for efficient API technologies and to choose between WCF and ASP.Net Web API Frameworks. And, start a blog series to showcase some of the ASP.Net Web API features and solution to common problems for API design.

SWIFT Message Validation Using BizTalk Accelerator for SWIFT

If you have hit this blog post, I would assume you already know BizTalk and you are looking out for ways to validate SWIFT message using BizTalk Accelerator for SWIFT.

Messages can be validated at any stage in BizTalk. It can be at the receive port, orchestration or at the send port based on the messaging needs. At receive port, inbound message can be validated for data constraints using Xml schema validation. I have to mention this here, flat file message schemas that comes through BizTalk Accelerator Message Pack has implemented data constraints and validations as per the SWIFT standards. We can leverage the Xml schema validation to validate the structure and data constraints of the message. In a typical BizTalk solution to validate the message, you can implement Xml Validator pipeline component in a receive pipeline and configured at receive location. Xml Validator pipeline component reports only first error and does not list all the errors present in the message. It does not make sense to correct\report one error at a time for a business partner.

SWIFT Disassembler Pipeline component that comes with BizTalk Accelerator for SWIFT has a robust functionality and can save us a lot of time developing a custom solution. Key functionality of this component is to dynamically discover the inbound message type, parse the flat file to Xml, de-batch messages, Invoke Xml validation and perform BRE validation. Most of the functionality can be controlled through configuration of properties.

Fig: SWIFT Disassembler pipeline component properties

SWIFT Disassembler Validation functionality perform a validation on entire message and reports all errors present in an inbound message. Also, we can control to perform either only Xml Validation or only BRE validation or both. SWIFT Disassembler component publishes parsed Xml message, validation error and promotes A4SWIFT context properties.

Validations errors are reported in the form of Xml as shown in the sample here.

<?xml version="1.0" encoding="Windows-1252"?>
<SWIFT_ERROR MessageType="101">
  <XmlValidationError Severity="Error" SchemaName="http://schemas.microsoft.com/BizTalk/Solutions/FinancialServices/SWIFT/Category1/MT101#SWIFT_CATEGORY1_MT101_Interchange" LinePosition="1482" LineNumber="1" ExceptionType="System.Xml.Schema.XmlSchemaException: The 'Line1' element has an invalid value according to its data type.">
    <Message>Incorrect format in Line1 for tag 59.</Message>
  </XmlValidationError>
</SWIFT_ERROR>

Messages with errors can be subscribed by a separate orchestration process to handle errors by setting up a filter as below.

Microsoft.Solutions.A4SWIFT.Property.A4SWIFT_Failed == True

Came through the word BRE above and wondering why it is required? Well, it is time to talk about it. BizTalk SWIFT schemas define data constraints. For example, an amount field is a positive integer and a valid format. But, it does not define cross field validation and Business Rules. For example, a MT101 Request for Transfer message which is sent to bank can be used for multiple scenarios. 1. A customer sending a request to bank for credit transfer initiation, 2. Interbank settlement. Set of fields would be populated based on the scenario MT101 message is used for. This would require a complex cross field validation to validate business rules. BizTalk Accelerator for SWIFT implements this as Business Rules Engine (BRE) Policies. In-addition, BRE policies also includes SWIFT network and usage rules with error codes. More information about SWIFT BRE Policies can be found here.

BRE Validation can be turned-on in SWIFT Disassembler pipeline component by setting the property. However, I have to caution here. Installation of SWIFT Accelerator does not deploy the Policies. It has to be deployed beforehand for each message type that will be used in the solution to successfully validate.

SWIFT Disassembler can be used to validate the message at the receive location. There might be many scenarios where we might need to implement the validation functionality in Orchestration process. For example, we might be constructing a SWIFT message to send it to bank by pulling the information from various backend systems. In this scenario, it makes sense to implement the validation functionality in orchestration.

BizTalk Accelerator for SWIFT has set of Utility API’s that can be consumed in orchestration and call a method for validation.

MessageValidator class can be found in the namespace Microsoft.Solutions.FinancialServices.SWIFT.Shared. This class offers the same functionality that is found in SWIFT Disassembler that include dynamic discovery of message type and apply appropriate schema for Xml validation and appropriate policy for BRE validation.

Note: I wrote this post based on BizTalk Accelerator for SWIFT 2010.

 

Cannot Install BizTalk Accelerator A4SWIFT Components

Ran into an issue while Installing BizTalk 2010 SWIFT Accelerator. A4SWIFT components were grayed out and could not install.

Resolution: Make sure you have all pre-requisites installed and workstation is on domain.

Microsoft Surface v/s Apple iPad v/s Google Android Tab

Microsoft earlier had revealed Windows 8 based tablets during its CTP announcement. A tablet is not a new thing to us. Apple was a game changer, and Google’s Android was a tough competitor. However, the announcement of Surface is a clear indication of shift happening with the computing devices “a post pc era” and how serious it is. Time has passed from PC era to handheld, light weight powerful computing devices such as Mobile and Tablets. Apple iOS and Google’s Android has a very sophisticated framework of application distribution and monetization called Marketplace was one of the reasons for the growth. Consumers were able to download the software on the apps on the go. Thanks to Internet evolution such as 4G and LTE technologies that fueled the growth. Microsoft was always into the serious PC business and had overlooked the consumer market except for gaming space Xbox. By the time it realized market capability through Apple and Google’s Android share on mobile devices, it tried to play a catch-up with its Windows Phone 7, but still a long way to go.

 

Natural evolution of iOS and Android to run on slightly bigger and powerful devices called Tablets had started posing a threat to heart and soul flagship product of Microsoft, Windows. This time there is no room for errors. Microsoft has invested heavily and strategically on building the core foundation from last couple of years with Windows 8, Marketplace, Windows RT, Skype integration to its products for collaboration needs (yet to see deep integration). At the launch of Windows 8, Microsoft had showed its ability to run on tablets in-collaboration with its hardware partners Samsung, Toshiba, Acer to name a few. Microsoft had earlier burnt its hands on hardware business except for Xbox so tried to follow its successful PC business model and partnered with its hardware manufacturers for tablets. Tablets produced from its hardware manufacturers was a lack of innovation and always tried hard to catch up with iPad design. This was bothering Microsoft. As a result, innovated its own tablet hardware and eliminated the pitfalls of iPad design and has addressed those concerns with its Surface tablet. Clear plus points for Surface tablet are kickstand, USB ports, well known and a familiar Windows OS.

 

Will Surface be a hit?

Majority of the Apple iOS and Android applications are consumer oriented. Apple is not enterprise friendly. With many versions of Android running on thousands of different hardware, it has become a fragmented market. More fragmentation with Android OS, applications become fragile and it would be hard for any enterprise to maintain different versions of the same app. And, both of these lack an eco-system to integrate with different enterprise technologies and make it hard for an enterprise. Microsoft has added advantage here with its OS compatibility, toolset and developer base, more importantly its ability to work with ISV’s

BizTalk Server ‘2012’ Road Map

Microsoft announced Integration platform road map focusing next version of BizTalk Server and Azure in a TechEd on June 14, 2012 held in Orlando. A well-known BizTalk veteran Kent Weare has put together a round up in his blog.

Here is the link for the blog:

http://kentweare.blogspot.com/2012/06/application-integration-futures-road.html

TechEd Webcast:

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/AZR207

Microsoft Windows Identity Foundation Cookbook – Book Review

Last week Packt Publications sent me copy of the book Microsoft Windows Identity Foundation Cookbook
and asked me if I can write a review. Book was a good read and wrote following review on Amazon.

“Implementing security is always been a concern and requires expertise to implement in the typical enterprise dealing with many technologies. Claims based Identity address the user authentication, authorization and single sign-on issue for an enterprise and B2B.

This book gives an insight and covers “how to implement” for common scenarios starting from ASP.Net, Windows Phone, iOS, ADFS, REST Services, SharePoint, MS CRM, Office 365, Windows Azure applications, Salesforce and Windows 8 Metro applications. A single book covering security dealing with many technologies is a challenge and author has explained and put together-well with the code.

I would recommend this book as a reference if you are implementing claims based identity or “wanna be” expert. ”

 

 

BizTalk : Feature: [Group] Failed to configure with error message [Error -2147217394 occurred configuring feature WMI]

Encountered an error “Feature: [Group] Failed to configure with error message [Error -2147217394 occurred configuring feature WMI]”
while configuring BizTalk Server 2010 ? This is an issue with the BizTalk WMI configuration corrupt or not added to WMI repository.

Resolution:

1. Open command prompt in administrator mode
2. Change the Path to “C:\Windows\System32\wbem\”
3. Execute command Mofcomp “C:\Program Files (x86)\Microsoft BizTalk Server 2010\Bins32\BTSWMISchema.mof”
4. Execute command Mofcomp “C:\Program Files (x86)\Microsoft BizTalk Server 2010\Bins32\BTSWMISchema.mfl”

Above commands add BTS WMI configuration to repository. You should now be able to configure BizTalk Group using BizTalk configuration wizard.

BizTalk Host Separation Strategy

There is no one thumb rule for separating BizTalk hosts. It is a good practice to separate hosts in a standard way. Consider following guidelines.

• Create separate hosts for Receive, Send and Processing operations
• Create new host if a specific throttling configuration to be used by Interface. Low latency, High throughput, Interface optimizations
• Create send and receive hosts specific to functionality\adapter
• It is necessarily not required for every Interface to create a new Host and Host Instances. Increasing number of host instances will cause a contention on a MessageBox database and resources may saturate and bring down overall performance.
• Host Instances can be shared across Interfaces. Share host Instances based on operation and functionality.
• Create new host if a Interface is memory\cpu intensive or critical or if it is experiencing throttling issues. This has to be assessed during performance tests.

 It is important to follow naming conventions  for proper separation strategy. Following is the guide line for naming hosts.

<type>_<bit support>_<sequence>_<functionality\adapter>

Eg: RxHost_x64_1_SQL . This is a receive host , with 64-bit, sequence 1 and running SQL adapter.

TFSPreview Invitation Code

Here is the Invitation code for TFSPreview.

a507ed33-cec0-4789-bd56-32a8b7a494ba (5 left)

Middleware in the Cloud !

A much anticipated feature of Windows Azure, Integration services is finally available as a CTP. I am thrilled with the release of Windows Azure Service Bus EAI and EDI labs and would be starting to dig into it.

Microsoft used to provide Enterprise Application Integration (EAI) and Electronic Data Interchange (EDI) capabilities through BizTalk. With the release of Windows Azure Service Bus EAI and EDI labs CTP, it envisions to provide same capabilities as Platform-as-a-Service (PaaS). It now unlocks the power of middleware in the cloud!

What is included in this CTP?

1. Enterprise Application Integration
   • Service Bus Connect : This feature allows an application in the cloud to communicate to Line-of –Business(LOB) system residing on-premises using LOB BizTalk Adapter Pack.For this release it supports, SQL Server, Oracle Database, Oracle E-Business Suite, SAP and Siebel eBusiness Applications.
   • Transformations: This allows transforming a message from one schema to another schema. This is a feature similar to BizTalk Map with a new face lift. Now the functoids are called Operations in Maps.
   • Bridges: Enable Service mediation patterns such as VETR (Validate, Extract\Enrich, Transform and Route)
2. Electronic Data Interchange: With Trading Partner Management Solution on the cloud, It is possible to configure to send and receive messages from Business Partners using the portal here.

To get started, download the SDK samples from http://go.microsoft.com/fwlink/?LinkID=184288 and the tutorial & documentation from http://go.microsoft.com/fwlink/?LinkID=235197