With the introduction of Deployment Models for business logic (Cloud Code), we also added support for “invocation chains”. This is an ability to chain together multiple server-side event handlers registered to process the same event. Previously, you could inject cloud code into the API invocation flow as shown in the image below:

For any API call, you could have only one before/after event handler with your own custom business logic. This is changing with deployment models and you can have multiple event handlers chained together:

This is a HUGE improvement. It promotes better design for cloud code with a clean division of responsibilities between the event handlers. It is important to note that any data received as arguments for an API call is passed from one event handler to another. If an event handler sitting at the beginning of the chain makes a change to an argument (or the return value), then all other event handlers down the chain will get the modified value.

Setting up chains in console

A question you might be asking is how to configure the order of the event handlers. This is done in the Backendless Console. Consider the following example:

As you can see there are three "beforeCreate"  event handlers for the "*"  context (which means they apply to every data table). When Backendless detects you have more than one event handler applicable to a particular context, it displays the “handler ordering” icon:

Clicking the icon opens up a popup where you can control the execution order for all applicable event handlers:

We’ll have a video posted to our YouTube channel with a demo of the functionality soon. That’s all for now, guys. Happy coding!

We are preparing one of the final Beta builds for Backendless 4. The build should be released early in the week of June 19th. We plan to release the service out of beta shortly after that. One of the important changes in the upcoming service update will be the introduction of deployment models. When the service is updated with that build, it will be necessary to redeploy your business logic (API Services, Event Handlers, and Timers) using the latest release of CodeRunner. If you do not do that, any existing business logic in the Backendless 4 apps will stop working.

We realize it is going to cause an inconvenience – we really wanted to avoid it. However, the service is in beta and we thought you’d cut us some slack.

If you have any questions about this, please ask either on the support forum or our slack channel.

One of the new features we will be releasing in the final update of Backendless 4 beta is support for “business logic deployment models”. This is a new concept introduced in Backendless 4. A “deployment model” combines individual API event handlers, timers and API services into a single group. The purpose of that grouping will become more apparent once we start opening up Backendless Marketplace for submissions, however, the introduction of this feature already opens some very cool features.

This change will be available in the Backendless 4 applications the week of June 19th.

Some important things to keep in mind when working with deployment models:

• Models are associated with languages. It means a model with the same name may exist with Java business logic and JS business logic, but it is not the same model – they will contain different business logic.
• A model cannot contain more than one API event handler attached to the same “asset”, which is a table/file/messaging channel. This means, for instance, if you have a JavaScript “afterUpdate” event handler processing events for the “Person” table and the event handler is in model “X”, the same model “X” cannot have another “afterUpdate” handler for the table “Person”.
• Contrary to what’s stated above, you can have the same kind of an API event handler in different models.
• When downloading code from the Backendless Console, you must identify the language and then the model for which to download the code.
• When deploying code using CodeRunner (JS or Java), the deployment model name for the code must be specified either in the CodeRunner’s configuration file or from the command line.
• Deploying code into a model deletes all previously deployed code in the same model.
• When the code is debugged locally (while being plugged into the Cloud servers), it takes precedence over the same code which may have been previously deployed. In other words, the Debug mode has higher precedence than the Production mode.

Let’s take a look at how to work with the deployment models:

Creating new event handlers and timers

When creating an event handler or timer in the Backendless Console you will see a new drop-down list where you can select an existing model. To create a new one, simply type in the desired model and click the menu option to create it. The screenshot below is for creating a new event handler. You will see an identical change in the “New Timer” popup:

The Event Handlers screen in console displays the model name for every handler (see the MODEL column):

When you download the generated code for event handlers and timers, you need to choose the model for which to download the code. The downloaded code contains only the event handlers and the timers for the selected model:

Similarly, if you were to edit the code directly in the Backendless Console on the CODING screen, you need to choose the language and the model. The displayed tree of directories and files will contain only the code for the selected model:

For most use-cases, you will find it sufficient to work with the same model. We considered how developers use business logic now and tried to make the developer experience mostly unchanged.

For anyone developing business logic in JS, we have put together some suggestions for troubleshooting your deployment. The page is added to the product documentation. One of the new features described in the doc is the ability to redirect console.log  messages to Backendless logging. Once your JS code is deployed to production, messages from the console.log  calls will be routed to the log file wit the SERVER_CODE  logging category.

Backendless API Engine is a service container enabling Backendless developers develop and run arbitrary Java, PHP and very soon JavaScript/Node.JS code as API services. With the service and CodeRunner update we deployed earlier this week, there is a awesome new feature which allows you to debug your services locally before publishing them into the cloud. The video below is an overview of the debugging process, it also briefly reviews the workflow for creating a new service. Enjoy!

We resume our webinar series with the plan to conduct two webinars a month. The first one is dedicated to the Backendless 2.0 release where you get an overview of the Platform and the new features of the release. Our webinars are interactive and you can ask us any questions.

Join the upcoming free webinar “New Backendless 2.0 Release – Overview and Highlights” and get a detailed look at the new powerful development functionality: geofencing, server-side logging API, node.JS support and API Engine – a powerful API management solution. 

The webinar will be useful for mobile app developers of all ranks – from a beginner to a experienced professional – as there will be plenty of tips & tricks to enhance your productivity in mobile application development.

When: Tuesday, June 30, 2015

Time: 12:00pm (CDT)  *to convert the start time for the necessary timezone, use World Time Converter

Duration: 1 hour (with Q&A)

Speaker: Mark Piller – CEO/ Founder of Backendless

NOTE: We are using gotowebinar system to conduct an interactive webinar. This service has a strong desktop / Android mobile service for registration Please use your any desktop or Android mobile devices to register for our event.

If you have any questions feel free to leave your comments or email below this post or contact elena@backendless.com with any issues you need to be clarified.

Register now  

The custom business logic feature in Backendless lets you add your own server-side code to handle client API requests. In this post I am going to review how to add the Data Service API handlers.

With that type of handler you can intercept and add additional logic for the APIs which store data in Backendless, run queries, update or delete data objects.

The easiest way to start building server-side Backendless code is the developer console. Login to your account, select an app and click the Business Logic icon. I assume there are some data tables in your backend, if not, make sure to create a few. Since we are going to add an event handler which works with persistent data, click Data Tables from the list of available handler categories. Click Add Event Handler, the screen should look as shown below:

Previously I wrote how to generate custom business logic code for API event handlers and how to locally debug your custom code. Now your code is ready to be pushed to the Backendless servers. Once it is out there, the Backendless infrastructure automatically handles scaling the code execution and routing requests to an instance available to run your code. The process for deploying an API event handler is very similar to the one for timers (see deploying custom business logic in timers to Backendless).

The ZIP file you downloaded from the Backendless Console (when it generated the code for an event handler) includes the deploying utility located in the /bin directory. To deploy the code, open a command prompt window and run the Deploy script. There are two of them, one for Linux (Deploy.sh) and the other for Windows (Deploy.bat). When you run the utility, it inspects all the custom code, packages and deploys it to the Backendless servers. The utility output would look similar to the one below:

Previously I described how to use the Backendless Console to generate custom business logic code. In this post I will describe one of the most amazing features in Backendless – an ability to debug custom server-side code on the developer computer before deploying it to the cloud. It would be very helpful for you to go through the previous feature to establish the surrounding context.

Once the code is generated, you can use the Download button to get a project archive (zip) with all the source code. In addition to the code the archive also contains a special command line utility which you can use to run the custom code locally. The trick of the local execution is the code inject itself into the API processing chain. This happens despite the fact that the API invocation is handled in the cloud, but the custom code runs on your computer. To put things in perspective, see the diagram below:

In my previous post I introduced the feature of server-side API event handlers – a mechanism for injecting custom business logic into Backendless. In this post I am going to review the process of creating an event handler for User Service APIs using Backendless console. The User Service APIs include: user registration, login, logout, user update, password recovery and retrieval of user schema (a list of user properties and their types). You can build an event handler (or two event handlers – “before” and “after”) for each of these operations.