Enterprise Mobility Patterns: Cross Platform Push Notifications

Push notifications have become one of the most commonly used features of modern mobile applications. Enterprise mobile applications also try to frequently take advantage of push notifications interfaces as a mechanism to distribute information between enterprise systems and mobile applications. Despite its popularity, delivering push notification across the different platforms remains a challenging exercise.

Part of the challenge  is based on the level of infrastructure required to abstract the communication between popular push notification services such as Google, Apple, Microsoft and BlackBerry. The level of brokering goes beyond the integration with the different services and includes other aspects such as connection pooling, retransmission algorithms, persisting messages etc. In the enterprise, this challenge is even more relevant due to the levels of security and compliance expected on different enterprise environment,

A simpler challenge but also interesting is to find the right level of abstraction that works effectively across all the different services. In KidoZen, we borrowed constructs from traditional publish-subscribe architectures and use a channel as the metaphor that describes the unit that apps can publish or receive data from via publish notification.

From the infrastructure standpoint, a traditional pattern is to implement a cloud base service exposes a publish-subscribe API and brokers the communication between the different push notification services. Using this model, the service will receive the subscription requests to a specific channel and will route that call to the appropriate push notification services. The following figure illustrates that:

pn1

Similarly, a mobile application can publish a message to a specific channel and the push notification gateway will distribute it to the appropriate push notification services. The following diagram illustrates this concept:

pn2

In this architecture model, the push notification gateway will be responsible for enforcing the correct security, tracking and retransmission policies required by that specific channel. While the push notification gateway pattern can be implemented as an on-premise service, the use of cloud computing techniques makes it exponentially simpler to scale, distribute and maintain the infrastructure required for this type of capability

 

KidoZen Webinar: Mobilizing your Enterprise Data: Patterns, Technologies and Techniques to Access Business Data from Enterprise Mobile Apps

Join us next week, we will be hosting our next stop on our series of webinars about enterprise mobile solutions. This webinar will be centered around mobilizing your enterprise data.  We will be digging into some of the architecture patterns around enterprise data and what different technologies and techniques are available for you.  That can allow you to incorporate better design principles into your overall enterprise mobile solutions.

Wednesday, April 16, 2014 1:00 PM – 2:00 PM EDT

Webinar Registration: https://www4.gotomeeting.com/register/638676263

Accessing enterprise data is, arguably, the biggest challenge of enterprise mobile solutions. From security, privacy to interoperability challenges, enabling the communication of mobile applications and enterprise data sources is far from being an easy endeavor.

This webinar examines the different technologies, architecture models and emerging trends that enable mobile applications to access data stored in enterprise systems. The session looks at two emerging trends in the industry: mobile data virtualization and mobile data management as the new foundation of mobile data access solutions. Finally, we will explore the capabilities implemented by the KidoZen in order to facilitate enterprise mobile apps to access data from corporate enterprise systems.

KidoZen Broadens Enterprise Mobile Platform-as-a-Service Offering with Mobile Database Services for Relational & NoSQL Database Connectivity

Yahoo-logobcom_small
digitaljournal-logo
KidoZen, Inc., the enterprise mobile-first platform-as-a-service Company, today announced the immediate availability of Mobile Database Services as part of its platform offering. Mobile developers can now quickly add native connectivity from their mobile applications to ten existing relational and NoSQL databases built in Oracle, MS SQL Server and MySQL, MariaDB, MongoDB, Redis, Neo4J, CouchDB, Hadoop or Elastic Search. Read More

Announcing KidoZen Mobile Database Services

Today, we are super excited to announce the latest addition to KidoZen’s enterprise mobile platform as a service: mobile database services. Integration with corporate databases are an essential component of a modern enterprise mobile infrastructure. However, those type of integrations typically require organizations to build quite a bit of infrastructure in order to securely expose their internal databases to mobile consumers. More importantly, that infrastructure looks very different depending whether we are integrating with relational, NOSQL, New SQL or Big Data databases.

KidoZen mobile database services provide a series of mobile-first APIs to integrate mobile applications with a group of the most relevant databases systems in the enterprise. This first release includes the following databases:

db services

The support for mobile database services has been included in all KidoZen mobile SDKs. With this addition to our KidoZen platform, mobile developers can now build sophisticated mobile applications across a dozen of different mobile platforms that seamlessly integrate with enterprise databases.

This is the first of a series of releases that expand KidoZen capabilities to integrate mobile application with enterprise data.

I hope you enjoy this initial set of capabilities. If there are specific databases you would like to see supported as part of the KidoZen platform, please send us an email to support@kidozen.com. Looking forward to hear your feedback!

March Conference Events: Chicago to London

The KidoZen Team has been busy hitting the road during March. We have had the pleasure of meeting with some great people and hearing what their organizations are doing with mobile solutions and where they are hitting roadblocks within their mobile strategies and implementations.  Thanks everyone, for participating in the many great discussions on all things mobile and of course KidoZen and the benefits of using an enterprise-first mobile platform.  Also, we are grateful for getting interactive feedback on where KidoZen is going in the next few months.
Thanks to everyone that took the time to chat with us at these great events.

CDM_MobilitySummit

CDM Media’s Enterprise Mobility Summit - Slide Share

managingBYOD

Managing BYOD & Mobility - Slide Share

Accessing Business Data in Enterprise Mobile Apps

Last week I had the opportunity to speak at the CDM Enterprise Mobility Summit in Chicago. The event brought together some of the top practitioners in the enterprise mobile space as well as executives from Fortune 1000 companies. This time, we decided to focus our session in the new area of mobile data virtualization and it’s rapid adoption in the enterprise mobile space.
You can see the slide deck below:

Mobile Testing: Page Object Pattern with Multilayer Design

You probably heard about the Pros and Cons of using Automation, one of the cons often mentioned is the high maintenance and low scalability of code, hence in this post we are going to give some best practices and design patterns to follow and mitigate this.

Often automation starts with a few scripts, you got some good results and you start adding more and more test cases, then you realize you have scripts with hundreds of lines of code, and as a consequence they are not easy to read, they have a lot of repeated code and they are hard to maintain and scale. Well if you want to automate your app on a big scale, you need to understand you are basically writing a program to test a program, therefore you need to follow the same coding principles that any developer follow.

Let’s define a scenario for example an App to manage expenses, with the following basic flows:

Flow (1)

You have many screens, with many actions and interactions between screens, so let’s talk about multilayer design, you can basically define 3 layers: UI access, functional flow and test cases layer.

UI access: Here you are going to isolate how you access to fields, buttons, etc. on the application running on the device by mapping all the objects, if you are doing it on UI Automation for iOS your code will have something like this:

...
//Login Screen
var userNameField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Username"];
var passwordField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Password"];
var loginButtonField = UIATarget.localTarget().frontMostApp().mainWindow().tabBar().buttons()["Login"];
var errorField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Error:"];

//Create Expense Screen
var createExpenseButton = UIATarget.localTarget().frontMostApp().mainWindow().tabBar().buttons()["Create Expense"];
var expenseNameField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Expense Name"];
var expenseDetailField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Expense Detail"];
var confirmExpenseButton = UIATarget.localTarget().frontMostApp().mainWindow().tabBar().buttons()["Confirm"];
...

Remember each control on the app will probably be used many many times on your tests, so why should I do this? because if and ID is changed your tests will start failing, but if you define a separate layer for UI access you only need to change the ID once.

Functional Flow: this layer will contain all the functional flows you need to perform actions on the screens e.g. to log in, you can create a function for each action and within the method, you’ll have all the interactions with the controls you mapped on the UI access layer, your code will be like this:


function userLogin(userName, userPassword){
	...
	userNameField.setValue(userName);
	passwordField.setValue(userPassword);
	loginButtonField.tap();
	...
	}

function wrongPasswordError(errorMessage){
	...
	assertEquals(errorMessage, errorField.value());
	...
	}

function createExpense(expenseName, detail){
	...
	createExpenseButton.tap();
	expenseNameField.setValue(expenseName);
	expenseDetailField.setValue(detail);
	confirmExpenseButton.tap();
	...
	}

You will have many functions with use many times the UI objects, but if one object changes and tests start failing you don’t have to worry, you only need to fix the mapping on the UI access layer once.

Test cases layer: You already have access to UI controls and functional flows, now you can use the flows to create test cases, since you have one function for each action, your test cases will be a chain of functions with their parameters, you’ll have something like this:

'A user login with correct credentials then create Expense'
...
userLogin("someUser","somePassword");
createExpense("expenseName", "someDetail");
...

'User login with wrong credentials, check error message'
...
userLogin("someUser","wrongPassword");
wrongPasswordError("wrong password!");
...

'User try login with wrong credentials,then retry, then create Expense'
...
userLogin("someUser","wrongPassword");
userLogin("someUser","somePassword");
createExpense("expenseName", "someDetail");
...

Now you can easily create test cases, you will use each flow many times, as you can see in the example, but you don’t have to worry if a flow is modified, for example: now the users have to enter an extra security code on the log in screen, they added a new textbox for that reason. Is not a big deal, you only have to add a line to map the new field and also add an extra step on userLogin function to set value on the new field. Now all the test cases that uses the login flow are working good again.

Together with multilayer design you can also implement Page object pattern, they are very related and one benefits the other. Page object pattern was thought for web sites automation on selenium but we can easily adapt to mobile apps, web sites has pages and mobile apps don’t, but they have screens .If you check the diagram with the application flows, you’ll easily figured out there are many screens that interacts each other, each screen has their own controls and their our functional flows, so why don’t put them together? Page object pattern propose to represent each screen as an object that encapsulates the functionality.

All we need to do is some re-factor on the code we have, let’s think in each screen as a class, then map only the objects that belong to the screen and also the functions that represents the functionality flows. Now we have a re-factored clean code that allow us to maintain it easily, and provide a good scalability to create many many test cases without loosing control.

JavaScript: The Most Popular (Programming) Language

 

In the last couple of years, JavaScript became the most popular programming language on GitHub.

But wait, what? Did you said JavaScript?

JavaScript have grown a very bad reputation mostly because of the bad browser implementations and because of the horrible DOM interface that came with them.

The whole story begin to change with one single man. Douglas Crockford.

He began to evangelize it with a couple of internal videos for Yahoo (like “JavaScript the programming language”, “An Inconvenient API – The Theory of the DOM”, and a couple more. I SERIOUSLY recommend everyone to watch these videos). And after that he wrote his master piece: “JavaScript: The Good Parts”.

JavaScript is the widest deployed programming language nowadays. It’s in every browser, smartphone, tablet. It’s responsible for what we called web 2.0 with its ajax stuff. It’s really amazing that the whole thing can be narrowed to the XmlHttpRequest object.

Mozilla began to pay attention to their JavaScript Virtual Machine implementation. Apple improve Safari as well.

Google Chrome’s V8: The VM breakthrough

Google developed V8, an open sourced C++ implementation of the ECMA Script 262 5th edition and everything changed. It really speed things up in JavaScript execution.

V8 was fast, really fast. And so it was Chrome. It became the fastest browser regarding JavaScript execution. But V8 was much more than just the Chrome’s JavaScript VM. V8 could be embedded in a whole new different kind of projects. In JSConf 2009 Ryan Dahl presented Node.js. He received an standing ovation, it was revolution.

Node.js reborn javascript in the server + non blocking I/O.

But let’s get back a litte.

 

The Misunderstood Language

 

As Douglas said in his book, JS has it’s share of good things and bad things. In this blog post we are making a brief summary of the things we loved about it.

  • Functions are first class citizens: You can create them, assigned them, passed them around. Once you get the taste of it you’ll love it.
  • Closures: Function objects can enclosed outer variables. This is a very powerful and yet dangerous thing. It’s still great that you can use functions this way.
  • Object Literals: How many times your preferred programming language let you create an object like this: {}? That’s all it takes to create one in JS. Or maybe you would like to add a name to it: {“name”: “SuperObject”}
  • JSON everywhere: You can create, read and pass it around with ease. Forget about old XML files. JSON native support in JavaScript it’s great.

These ones belongs to Node.js:

  • Only one language: Thanks to node.js you can build your server components and you browser client stack with just one language.
  • Module System: The “module.exports / require()” functionality it’s really simple and powerful. It let you modularize your code in a pretty simple fashion
  • NPM: Ok, this is not node.js, but it’s also great. A giant ecosystem of packages with everything you will ever need.
  • Non blocking I/O: This is the leitmotiv of the technology. Use the CPU time to do useful staff instead of waiting for I/O to be available and minimize memory footprint in the meantime.

 

Of course it has it’s fair share of bad (and someones awful) parts, but the good ones are pretty amazing.

We, at KidoZen have chosen javascript and node.js as two of our main technologies and the journey, so far, has been awesome.

 

Enterprise Mobile Patterns: App Authentication

This is the first of a series of blog posts that explore some of the most common patterns in enterprise mobile solutions. We’ve observed variation of these patterns in hundreds of solutions with KidoZen customers and we thought it might be a good idea to document some of them so that mobile developers can leverage those principles when building enterprise mobile solutions.

To keeps things entertained, we’ve decided to start with one of the most common and yet very difficult patterns to implement in enterprise mobile applications: mobile-app authentication. In this scenario, a mobile application needs to authenticate with corporate credentials to a corporate directory such as Microsoft Active Directory and subsequent tasks of the apps should be performed on behalf of the authenticated user.

From a development standpoint, authenticating mobile apps to corporate networks involves interoperating mobile applications with identity management protocols such as SAML, WS-Trust or OAuth which are the cornerstone of enterprise identity systems. Creating that level of interoperability is fundamentally challenging as most mobile application suites don’t implement those protocols natively.

From an enterprise standpoint, there are a handful of well-established practices when comes to enable mobile app authentications to a corporate network. Some of those practices include building custom authentication APIs, using app containers or leveraging enterprise mobile backend as a service (mBaaS) platforms like KidoZen.

The Custom API Approach

Arguably the most popular approach in the enterprise, this model includes a custom service API that brokers a corporate directory such as Microsoft AD in order to integrate with mobile applications. The following diagram illustrates that approach.

Auth-1

While the proposed model is fundamentally simple, it has some major drawbacks. For starters, the custom auth API approach requires an additional level of infrastructure that needs to be implemented by enterprises. Additionally, custom built authentication APIs rarely implement the complete set of identity management protocols required at the enterprise level. In that sense, many enterprise end up compromising security in order to achieve the required interoperability with mobile applications.

The App Container Approach

A model that has become popular as part of the mobile device management (MDM) systems, is to wrap mobile enterprise mobile apps into a container which is also responsible for authenticating to the corporate network. The following figure illustrates that approach.

Auth-2

The model illustrated above completely abstracts the authentication capabilities from the mobile application itself which makes the experience extremely simple from a development standpoint. However, the level of abstraction prevents individual authentication needs from specific applications as the experience is controlled at the container level. Similarly, the applications need to be designed to operate in a container mode which makes portability extremely difficult.

The Enterprise mBaaS Approach

This model has been mostly pioneered by enterprise mBaaS platforms like KidoZen. In this approach, the enterprise mBaaS will provide an identity federation layer that also provides the authentication APIs for the mobile applications. Using this model, mobile apps will leverage the authentication API of the enterprise mBaaS layer which will, in turn, federate the identity with the corporate environment. The following diagram illustrates this approach.

Auth-3

The proposed model presents a simple options for developers while leveraging the robustness of enterprise-ready identity management protocols. That pattern can also be easily adopted in public, private or hybrid cloud scenarios which makes it really appealing for enterprises.

These are just some of the most common patterns in order to enable authentication to corporate networks from enterprise mobile applications. We would love to hear your thoughts.

Securing data access with DataSources

Enterprise APIs in the Wild

Using our services you can connect your mobile applications to a whole stack of back-end services like Sharepoint, Google Drive, Google Calendar no matter if they are in the cloud or running in your own organization servers (on-premise).

This services are instances of our open-source connector’s suite which, once they are configured, exposed all the features of the back-end to your applications. Even though you can secure your services with our role-based authorization (see our docs at http://docs.kidozen.com/services/authz/ ), what if we would like to expose only a few business functionalities instead of the whole service?

 

Generic Interface Connectors

At KidoZen we are always trying to improve our enterprise features. Our latests connector (PostgreSQL, MySQL and SQL Server connectors) API expose a generic method “query” which receives a SQL Statement. This Statement could be a simple “Select” statement, an “Insert” statement or even a “Create Table” statement.

In the classic SQL World we have SQL Views and Store Procedures. This two features also could be used to securized our data. This two concepts bring us to our new functionality.

 

Entering DataSources

A DataSource is a predefined query using an already configure service. Following our datasource documentation we’ll be creating a new DataSource for a predefined Select Statement using our new PostgreSQL Connector.

First we have to create a new PostgreSQL Service:

Using an administrator account, as usual, we click on the Admin Section -> Enterprise API -> Services:

Selection_005

 

Then we select the PostgreSQL Service to create a new instance:

Selection_006

 

We’ll be running this service on-premise using an already configure agent.

We enter our PostgreSQL server configuration and click on the “Add” button:

Selection_007

 

 

We test our new service instance clicking on the “Test” button.

We would like to retrieve our product list so we enter the following test information:

  • Method: “query”
  • Body: { “sql” : “select id, name, price from products” }

 

And click on the “Invoke” button to test our new service.

Selection_008

We think that a lot of applications we’ll be using this query so a cache result set will improve performance. Also there are a couple of applications that shouldn’t access other tables in our database. Neither should change our data on the products table.

This is a perfect scenario for a datasource.

After we tested successfully our service we can create a new datasource from this same window clicking on “Create Data Source”:

Selection_009

 

Then we complete the datasource configuration, setting an hour valid cache timeout:

Selection_010

 

Now we can invoke this datasource through our API without worrying about someone messing with our data.

 

[x]

Contact Us

You can call us at 877-513-3113, email us at
info@tellagostudios.com or complete the following form: