Skip to Content

I finished my Syclo Training on SMART Work Manager. This blog will point out my first thoughts on Syclo as a Product. A little bit about my background. I have been associated with Mobility all the while at SAP and have some basic idea about MI, but worked mainly on DOE/NW Mobile and later on SUP. The first fundamental difference that I noticed with Syclo is that there Middleware Server (Agentry Server) doesn’t store data. All the while both at SAP & Sybase the fundamental premise was, that in order to build offline applications you essentially need to stage Data on a Middleware and then distribute it to various devices, this was done primarily to provide flexible distribution and also to handle conflict detection. However Syclo takes this exactly in the opposite direction and has a Mobile Platform (for offline/complex/process apps) that doesnt stage data in a Middle Tier. And they have done this quite successfully with the SMART Work Manager and other applications that they have. The next obvious question is whether they will be able to scale up their architecture if they are not storing devices in the Agentry Server, I don’t have an answer to this question, maybe they can scale. But I would like to see real customer scenario’s where they have scaled for large data volumes. The other point related to conflict detection (An example of conflict – When a user changes a data in the mobile device and same data is changed in the backed). Syclo doesnt really have conflict detection. They post it to the back-end and its upto the backend to decide whether to accept it or not. Ofcourse they do have a concept of Exchange Object which can be used to identify Delta, then the Exchange Object can be used for conflict detection. However this will only indicate whether an instance has changed or not. There will be field/row level conflict detection possible without staging data in the Middle Tier. But again the point the backend is the driver of business data so its best for the back-end to decide what to do with the data. This leads to the next important point. Syclo Agentry Platform was built more from a business perspective. They have paid attention to what the business requires in terms of mobility and built the product step by step.

The other important point that I realized from Syclo’s architecture is that there Mobile Platform was built first by looking at the business and then the product was built to cater to those needs. Things such as adding a field in a UI or changing/disabling a field in the UI is very simple using the Agentry Editor. This is an important consideration especially when you are customize and app which invariably will happen when you implement a solution at a customer solution. Building an application from scratch with Syclo requires a lot of time, effort and money, but that should be the way it is especially if you want to build (complex/process apps) for the mobile devices that mimic the functionality of the back-end on the mobile devices. Because the apps that you are talking about is process intensive in nature. However if you have a solid product that needs to be customized or enhanced for a particular customer because of specific requirements at the customer site, its fairly easy to do it using the Agentry Platform. This is a very important consideration because most customers have requirements to enhance their functionality.

Syclo also supports cross platform development. It eliminates the need to generate, modify & maintain custom application code for every mobile OS. They use the Syclo Editor, Syclo Server & Syclo Client to achieve cross-platform portability of mobile solution.

    Syclo Client – You develop the appliation using Syclo Editor and the resulting application definitions are published to the Syclo Server, NOTE: they dont compile it to native code.

    Syclo Server – Manages all communication, synchronization, security & integrations acts as an integration server between mobile client and the SAP Backend. It also stores the application definitions.

    Syclo Client – Basically its a native OS mobile application that understands the application definitions and renders the mobile application on the device. So the app provides you with Native Look and Feel.

The most important thing about this model they have is easy maintenance of application across different mobile platforms. Of course other points such as saving development time, project cost etc…

To summarize, I am fairly impressed with the way Syclo Platform as whole. Especially there customization/enhancement concept for extending the application. In addition there attention to detail for changes to the UI that most customers want and ease with which you can achieve them. Of course I would like to see more data to prove the scalability of the product.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Dinesh Kumar Dhunde

    Good Morning Mr. Surendran, we are trying to develop a project involving Syclo, but since a week we are stuck at a very basic stage of downloading and installing the Agentry. Can you please share the basic tutorials and other stuff regarding Syclo which will help us in moving forward.

    Thanks

    Dinesh

    (0) 
  2. David Clavey

    Just a quick comment on Syclo Agentry server storing data, to quote:

    “Middleware Server (Agentry Server) doesn’t store data”

    Actually it can store data in either Tables or Complex Tables. Both of these being available typically for client side off-line lookup e.g. For filling Combo Boxes or form validation.

    (0) 
    1. Jason Latko

      David, the original poster is correct in saying the Agentry Server doesn’t store data.  The server acts as a conduit between the backend SAP (or any other) database and the client to deliver real-time up to the second data from that backend.  It is true that there is no snapshot or staging of out of date data on the Agentry server.  When a client connects to request data from the Agentry server connected to an SAP backend system, BAPIs are run real-time to get the current data and send it down to the client in the form of client side complex tables, data tables and object collections for display and editing locally on the device.

      (0) 
      1. David Clavey

        True. But a Agentry Server without some kind of database is a dead beasty. Like a dragon with no legs or wings.

        I can’t say what I meant four months ago, but I believe I was comparing Syclo with SUP, with the work manager product the extra tabls created on the SAP platform are very simular to the SUP cache idea, be it with no real duplication of data stored. Both systems have pro’s and con’s. A well deigned SUP MBO has a lighter touch on the SAP backend system. A well design Syclo module integrates with the SAP backend in a much more elegent way.

        I like both approches.

        Roll on SMP 2.3 🙂

        (0) 
        1. Michael Appleby

          Hi David,

          The Agentry Server contains security information, connection information and the meta data definitions of the application present on the Agentry Clients (mobile devices).  All data whether Complex Table, Data Table or Objects (as well as data held in associated Transactions) are passed through the Agentry Server during Transmit (which kind of corresponds to Synchronization). 

          If you think in terms of the Cache Database on a server sitting in the middle which provides synchronization, then the corresponding functions in Agentry are not located in the Agentry Server, but rather are contained in the Addon functions that are bolted on to the ERP system (or whatever type of backend).  The elegance is that it resides in the same system as the backend data and uses many of the ERP ABAP functions as well as those Exchange and Delta Detection that come with the Agentry Addon.  So synchronization is really handled by the heavy duty hardware of an ERP system and only a very light load is required at the Agentry Server which basically is a pass through system.

          So the only copies of data in an Agentry application reside on the mobile devices themselves and in the backend.  So it is only a two point synchronization.  With the use of a Cache Database, there are three nodes that need synchronization:  mobile device, cache database, and backend.  The Agentry approach is simpler (at least for synchronization) and makes use of the heavy duty horsepower of the backend rather forcing it on the middle node.

          Regards, Mike

          (0) 

Leave a Reply