Month: October 2017

Testing an ESB with Selenium!

Manual integration testing is the first “test plan” in application development. This strategy quickly becomes a pain, so introducing automation early is important with any project. When working on an enterprise service bus, automated testing is a must have. Early in the development of Orbital Bus we began implementing automated unit tests and even automated integration tests in our continuous integration pipeline. Scripting such tests is a common approach for similar ESB projects. Why are we writing an article about Selenium then? Eventually we decided that console applications weren’t enough. It’s very common to have web applications that call to multiple micro-services via an ESB, so we wanted to build one and test it out. How would we automate those tests? We chose Selenium.

 

Selenium is an open-source testing solution for web apps. Selenium helps you automate tasks to make sure your web application is working as you expect. Selenium has multiple tools:

  • Selenium 2 (WebDriver): Supplies a well-designed object-oriented API that provides improved support for modern, advanced web-app testing problems.
  • Selenium 1 (Remote Control): Provides some features that may not be available in Selenium 2 for a while, including support for almost every browser and support of several additional languages (i.e. Java, Javascript, Ruby, PHP, Python, Perl, and C#).
  • Selenium IDE: Helps with rapid prototyping of tests with Selenium for experienced developers or beginner programmers who are looking to learn test automation.
  • Selenium-Grid: Allows for tests to run on different machines and in different browsers in parallel.

For Orbital Bus, we used Selenium 2 since it supports nine different drivers (including mobile OS’s). That ensures going forward we can adapt our tests however we need.

We know Orbital Bus will be an essential component in a web application, so we needed to test the ability of Orbital Bus to handle a lot of requests from a browser-based application. By stressing Orbital Bus with a lot of requests, we could verify that our message broker receives and delivers the messages properly and the Dispatcher and Receiver handles and translates the messages as expected.

In addition to Selenium 2, we needed to use a web driver to conduct the testing. We chose the Phantomjs Driver. This driver is “headless”, meaning we were able to manipulate all the elements in the page. Keeping in mind we wanted to stress test the system, we weren’t concerned with complicated UI scenarios. We were using Selenium just to fire requests and make sure that a UI element changed showing receipt of the response. Other test harnesses for browsers often open extra pages to capture the screen. That kind of interaction was beyond our scope. We wanted to just focus on messages getting through. The following code section is an example of our tests.


public void RequestsForYahooWeather()
{

var countryJsonPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Configs", "countries.json");
var jsonString = File.ReadAllText(countryJsonPath);
List countries = JsonConvert.DeserializeObject<List>(jsonString);

foreach (country countryO in countries)
{
var driver = new PhantomJSDriver();
WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10));
driver.Navigate().GoToUrl("https://localhost:55794/Home/Weather");
IWebElement wElement = driver.FindElement(By.Id("CityName"));
IWebElement wElementTemperature = driver.FindElement(By.Id("Temperature"));
wElement.SendKeys(countryO.capital);
IWebElement wElementButton = driver.FindElement(By.Id("getWeatherInfo"));
wElementButton.Click();
Assert.NotStrictEqual("-", wait.Until(drv => drv.FindElement(By.Id("Temperature")).GetAttribute("value")));

driver.Quit();
}

}

Our experience with Selenium was easy to implement and quick in performing the necessary tests. Our tests successfully passed, demonstrating that Orbital Bus can work with web applications and have no negative impact over console apps. Selenium not only let us confirm Orbital Bus was working as intended with a web application, but it will afford us with the flexibility and performance needed to grow these tests in the future as we expand our use cases.

 

  • Maria
  • Reyes Freaner

Getting Started with Orbital Bus

You’ve heard people talk about enterprise service buses and you think it’s time you learned out to use one. You read an awesome blog post about this new thing called Orbital Bus and you think it would be a good project to play around with. Where should you start? Let’s start here.

Understanding the Architecture

I’m sure you’ve checked out our project README, but just in case you need a refresher here’s a quick overview of how Orbital Bus works.
Everything starts with the Producer and the Consumer. The Producer produces calls into the system. These calls can be synchronous requests or asynchronous fire-and-forget messages. What’s important is that the Producer is what initiates the action. The Consumer consumes messages off the queue. Both the Producer and Consumer are external to Orbital Bus. They might be third-party services, COTS products, or custom code applications made by your developer(s). The Orbital Connector is a library the Producer uses to get messages into the system. We have a whole project dedicated to connectors. The Connector uses RabbitMQ to pass messages to the Dispatcher. The Dispatcher listens for incoming messages, finds services via Consul, and sends messages to the Receiver via it’s queue. Receiver’s do the heavy lifting. They load custom libraries, transform messages, and use adapters to send messages to the Consumer.
Here’s a diagram to give you an idea of the general flow of information:
An overview of the Orbital Bus flow.
An overview of the Orbital Bus flow.

Getting ready

For this little test, let’s put everything on your local machine. You’ll need to prepare by installing two third-party components: Consul and RabbitMQ. We use these for service discovery and message communication respectively. If you want some help you can check out our more detailed instructions. Since Orbital Bus is ready to communicate with any RESTful web service, we’re going to use JSONPlaceholder. Feel free to check it out and get a feel for the kind of messages you want to send.

Build a Producer

The Producer is the instigator of the pipeline. It calls out using the Orbital Connector and RabbitMQ to get the Dispatcher communicating with other nodes. Since our current Orbital Connector is written in .NET, you’ll want a .NET application that references it. We have a NuGet package to make it simple. We have four methods for sending with the connector: synchronously, asynchronously, synchronously that can be awaited, and a one-to-many route. We recommend starting with a synchronous call. All the producer needs is the service ID for the destination service (which you add to Consul below) and a JSON-serialized payload.
For more detailed instructions on making a Producer, check out our How-To Guide. It’s got a thorough process with code samples and everything!

Use Code Generation

Next we’ll setup the side of the Consumer. As we said above, we’re not going to bother building a web service (though you can if you really want to).
To get started you’re going to have to download the Code Generation project. We made this tool to help generate the necessary libraries for the Orbital Bus Receiver to connect with a service. All the files you work on for Code Generation are Javascript, so your C#, Java, Python, and Ruby developers should all be able to use it. Of course we have a handy guide to making a library. When you’re done building your library keep track of the `bin` folder in the project directory. We’re going to need all its contents.

Configure your Nodes

I know what you’re thinking: “Where’s the actual Orbital Bus?” That’s the beauty of our distributed system. The bus has no central hub to stand up. Each service has a node or nodes that live alongside it to facilitate communication.
To get our local instance up we’ll need both a Dispatcher and a Receiver node. You can download them on our release page. With the release package unzipped in a location of your choosing, you’ll want to copy over your code generation output. Remember that bin folder we told you to keep track of? Copy all its contents into the Plugins folder for the Receiver. The Receiver will pull in those libraries at runtime and then it’s ready to communicate to your web service.
You’ll also want to set the values of the configuration files to the appropriate values for your local deployment. We have a handy article about all the configuration properties. Be sure to open up any ports you’re planning on using for your Dispatcher and Receiver!

Run!

Now it’s time to set everything in motion! If your Consul and/or RabbitMQ aren’t already running start them up. Start up your Receiver and register it with Consul. (We also have a Consul Manager tool in the release package. Check out this article to see how you can use it to register your service.) Start up your Dispatcher and your Producer and start sending messages!
If you’ve run into any snags or want a more thorough description, check out our How-To Guide. It describes each step in detail so you can see how every part of the process should be configured.
What’s next? Try implementing a second call. Check out our other documentation, like our Handshake Diagram to better understand the paths of the messages. Maybe add another Receiver with another web service to give you an idea of multiple nodes on the network. Hopefully this test will be a small step along your long future with ESBs. Enjoy!

  • Joseph
  • Pound

IT Organizations Need to Practice More, Dunk Less

Whenever I walk into a new client, the first things I hear from the Technology Executives are typically: “We need to modernize”, “We need to transform”, “We need to adopt <insert trendy tech buzzword>”. What I never hear is: “We need to bring our development and testing methodologies up to date”, “We need more collaboration across our teams”, “We need to inventory our skills and see what’s missing”.

If we think of the IT organization as a basketball team, that would be the equivalent of the coach saying: “We need more 3-pointers”, and “We need those fancy new shoes to be able to dunk”.  Whereas even the most inexperienced youth coach knows that the key to winning includes: “We need to practice dribbling and footwork”, “We need to communicate better on the court”, and “We need to improve our free throws/jump shots/rebounds”.

While it is both valid and necessary for IT organizations to push towards the big picture objectives highlighted by glossy Gartner and Forrester whitepapers, these have to be supported by continuous and deliberate investment in foundational concepts.

Let me step in as coach for a moment and propose a strategy for focusing on the foundation…

1)    Invest in the basics: Invest in good basic IT delivery concepts, kind of like dribbling, footwork, and basic fitness in basketball:

  • Make Business Analysis about teasing out the requirements from the Business’ objectives, rather than simply asking the Business to write down their requirements
  • Encourage good testing rigor and embed it throughout the entire solution delivery lifecycle, and not just at the end just before go-live
  • Promote good documentation habits and create templates for common documents (e.g., logical solution architecture, functional designs, interface specifications, data models)
  • Spend adequate time and budget to implement solutions which improve developer productivity (e.g., continuous integration, 3rd party frameworks)
  • Allocate budget for developers to learn different languages so they can be exposed to different software concepts and improve their coding skills
  • Spend generously on training for system analysis, modeling, design methodologies (e.g., domain driven design, SOA, microservices architecture, semantic modeling, BPMN), and not only on those being standardized by the organization, but to improve people’s ability to make smart decisions

2)    Communication is key: Create an environment that promotes collaboration and teamwork:

  • Create communities of practice across your organization (or connect to external groups) to build on collective knowledge and experience
  • Implement real-time collaboration tools (no, Sharepoint and instant messenger don’t count)
  • Make governance less about formal approvals and more about ensuring the right expertise is pulled in at the right stage of a given project
  • Adopt iterative delivery methods to promote frequent touch points between IT and Business obtaining feedback and ensuring alignment

3)    Focus on the right skills: Build the skills that support your strategic objectives. After all, dunking is only made possible by training to jump higher:

  • Strengthen Information and Data Management capabilities as a foundation for Big Data Analytics
  • Educate the team on hashing algorithms, binary trees, digital contracts, and distributed storage to bring Blockchain to the table naturally
  • Leveraging Cloud means good distributed system design, loosely coupled interfaces, container-ready applications, and security frameworks that can deal with 3rd party infrastructure
  • Adopting COTS requires strong technical Business Analysis, ability to negotiate requirements with the Business, and strong platform administration skills

We all want to work with the cool new tech and follow the latest trends. Working with the latest and greatest is what draws people to technology work. But the team will be stronger if the foundation is strong and the team is well connected so take time to build our own skills and our teams’ foundations so we can all up our game.

  • Shan
  • Gu