Tag: .NET

Modernizes BizTalk with

To stay relevant, today’s businesses have to adopt SaaS applications, cloud services, and API technologies and integrate them with their legacy systems. In SearchSOA this week, MuleSoft customer and Citrix integration developer Vinod Sangaraju discussed how Citrix has deployed CloudHub and is planning to use MuleSoft’s new solutions for to fill BizTalk integration gaps.

Vinod Sangaraju, Citrix Integration Developer


Citrix Systems integration development manager Vinod Sangaraju found the MuleSoft Anypoint Platform when searching for an iPaaS solution to connect Citrix solutions with Salesforce, Marketo, Workday, and other cloud and on-premises applications. His search was driven by Microsoft BizTalk’s limited SaaS connectivity. His team had been filling that gap by using Microsoft BizTalk for on-premises integration scenarios and MuleSoft’s Anypoint Platform, in particular CloudHub, for cloud-to-cloud and cloud-to-ground integration. That wasn’t ideal, he said.

The recent release of the Anypoint Connector for .NET opens up many opportunities for plugging into based rules engines. Since the Connector allows developers to call out to native .NET code, these rules engines can be easily integrated as a result.

Anypoint Platform .NET solution

Why do I want to do this?

Utilizing a rules engine promotes efficiency in system interfaces where some business logic needs to be executed and this logic can be frequently updated. You could wire all of this logic into your integration application via custom code or using several routers but these rules become difficult to maintain in code and may require several re-deployments as changes are introduced. Using a rules engine allows developers to decouple business logic from integration logic and as a result, rules can be easily maintained.

Aaron Landgraf on Thursday, July 31, 2014

10 Reasons to Walk from BizTalk

0

MuleSoft’s vs. BizTalk Server

Have you ever wondered if you should choose Microsoft BizTalk or MuleSoft’s Anypoint Platform? Below are 10 points to consider when deciding on the best integration solution for your organization:

1. Extensibility to Best of Breed

BizTalk Server promotes a tightly coupled model in which many of the services are bundled within the product. While this is great for compatibility it limits the ability of companies to use 3rd party applications that may provide better functionality. MuleSoft has built Anypoint Platform to be open and extensible to best of breed services and applications.Best of Breed

Included with Anypoint Platform are 120+ Anypoint Connectors for the most popular applications on the market, including Salesforce.com. Our broad partnership with helps us deliver a secure, reliable, comprehensive integration.

When you’re not using pre-built connectors, MuleSoft’s DevKit allows your developers to quickly build Mule extensions that integrate directly with Anypoint Studio, the single graphical design environment for Anypoint Platform. This broad connectivity solution enables you to deliver integrations in days or weeks, not months.

 

Announcing MuleSoft’s solutions for Microsoft!

Today, we announced the launch of MuleSoft’s Solutions for Microsoft. These new solutions enable companies to leverage existing Microsoft IT investments and integration logic written in .NET on Anypoint Platform™. Using our new .NET Connector and MSMQ Connector, developers no longer have to to be siloed by coding language or development framework. With MuleSoft’s solutions for Microsoft, developers can customize Mule application logic using any .NET language and familiar .NET development tools, including Visual Studio.

We see tremendous potential in these new solutions, as they unlock opportunities for Microsoft customers to address immediate integration challenges and develop a robust cloud and API management strategy for the future. Here’s what’s new:

A Step-By-Step Guide

SaaS applications like Salesforce have proven to be highly disruptive for many architectures.  In this multi-part blog series, we’ll demonstrate step-by-step how -centric organizations can use existing assets (e.g. legacy .NET applications, SAP) to maximize the value of their investment without disrupting underlying code.

Scenario:

In Part 1 of this blog post series we will explore a scenario that has an Auto Insurance company building quotes that allow customers to evaluate their premiums.  As part of this process there are some complicated quote calculations that must take place. These calculations take into consideration a customer’s age, driving record, level of education and location. These calculations are proprietary to the organization, provide a competitive advantage and have broad impacts if mistakes are made while building the calculations in the Quote system.

SaaS and APIs have changed the IT landscape. Applications you need to connect to now and in the future will be in a variety of languages and likely not in your datacenter. Limiting your next generation integration server by code base or deployment architecture will handcuff IT innovation, limiting your company’s ability to embrace future opportunity. .NET developers looking to get their company connected should think through these five questions before starting on their journey to a modern, loosely-coupled architecture.

How do I expose services in the style preferred by each client?

API ProtocolsThere are two major schools of thought for web services: / and REST. Given the large number of legacy systems in place in a typical enterprise, your integration software should meet the demands of each approach regardless of what is used by a given service. A modern integration engine can perform the heavy lifting to translate each message from the surfaced API into the form used by the target service. It can then transform and route messages while bridging different protocols along the way (e.g. HTTP to ). Using this method, clients become less dependent on interface and protocol requirements and service owners can vary services over time to meet changing business requirements while mitigating down time.

When looking at options for your next generation integration platform, the development language of the underlying ESB should not be a primary concern. teams in particular often constrain their search to only -centric ESBs, ultimately leaving them few options. If you find yourself in this position, here are a few things to consider:

  • At its core an ESB is all about .
    A strong ESB will support a broad range of standards, protocols, and adapters, enabling integration of services and applications written in any language or platform. A Best of Breed ESB doesn’t care if the services it is connecting are written in Java or C#.
  • A Best of Breed ESB will enable the majority of integration work to be done through tools that are easy to learn and provide visibility into what is happening in the ESB, rarely requiring developers to write or debug code.
  • When code is required for customizing integrations, the ESB should provide frameworks, APIs, and templates for the customization. So, for example, a .NET developer customizing a good Java-based ESB would use a small subset of Java, primarily needing to understand Java syntax, not the full breadth of Java technology. A Best of Breed ESB should also be extendable with other familiar languages, such as JavaScript or Python.
  • Java and C#, the predominant languages in the enterprise, are nearly identical in syntax.

So how should you choose the best ESB solution? As you begin the journey to evaluating your next generation integration platform there are critical components that will help you connect, implement, and deploy faster:

The standard was created to address the communication needs between different applications independently of the programming language, platform or technology in use. It is a standardized protocol based on XML over a variety of communication protocols such as HTTP, to invoke methods on remote objects. In this blogpost we’re going to consume web services implemented with the Microsoft Windows Communication Foundation framework (WCF) from a Mule application.  is part of the framework since version 3.0 and provides the building blocks to expose C# and VB.NET methods as SOAP web services, hosted on the IIS web server.

Wey Cheng on Friday, September 25, 2009

Interoperating With .NET Web Services

1

There are use cases where you may want to send a message through HTTP, File, or another transport to a Web Service. Using Mule ESB, it’s fairly straight-forward to accomplish this.

Consider this use case: