SAP Syclo Inventory Manager RDS Implementation

SAP Syclo Inventory Manager RDS Implementation for a Leading Global Chemicals Company with Motorola MC9090 Rugged Handheld Devices

Traditional ERP systems were designed and built for office workers that have access to a desktop. However, within several industries, majority of their workforce are situationally away from desktops and carry out company critical tasks away from a desktop – Sales, Field Services, Warehouse and Plant Maintenance operations. These workers are disconnected from their company’s backend systems and do not have timely access to information or the ability to process information at the point of contact or occurrence.

A global leading chemical company, approached Innovapptive for a solution to connect these mobile workers and better manages their warehouse operations, to save time of their workforce, reduce errors, rework, and cut costs by connecting their employees to vital inventory and supply chain information from their SAP systems.

Background

Our client provides specialty chemicals and has operations in three continents, with over 25 plants and 75+ warehouses and was looking to replace their inefficient paper based processes and implement a mobile solution to improve productivity of their entire supply chain workforce. Our client’s operations are extremely asset intensive and require substantial MRO inventories to keep their equipment up and running. In addition, the company was struggling with an inefficient process to maintain accurate inventory levels, and also meet customer order fulfillment from their 75+ warehouses.

Given the manual and inefficient processes to maintain accurate inventory levels, and lack of visibility into up to date stock information, our client was looking for a mobile solution which would require minimal manual intervention and faster turnaround times to view or process critical inventory information.

Innovapptive Solution

Rugged Mobile Devices for Syclo Inventory Manager Mobile App

Innovapptive proposed to implement the SAP Syclo Inventory Manager Mobile solution Innovapptive’s leveraged its SAP qualified Rapid Deployment Solution (RDS) and conducted a thorough requirement gathering and GAP analysis to implement the SAP Syclo Inventory Manager App. The pre-configured Rapid Deployment Solutions (RDS) was an attractive option to the customer as it is a defined time, defined cost and defined scope putting processes to work in a much clearer position. The Innovapptive RDS is delivered with supported guides, educational material and training of the Syclo/SAP Inventory Manager app to enable end-user easy adoption into the new system. Our team installed the SAP Agentry platform and customized the SAP Inventory Manager mobile application to meet customer requirements in less than 9 weeks.

As a result of this mobile solution implementation, our customer was able to easily maintain up to date stock levels, enable their field personnel to easily locate parts, tools and material they need, thereby dramatically reducing any inherent delay of operations.

In less than 3 weeks of the roll out, the customer had the ability to immediately improve visibility across the value chain, thereby tightening their supply chain and reduce inventory carrying costs which drastically reduced any service delays and prolonged outages and failures.

Innovapptive Solution Salient Features

• Receive, issue, and transfer inventory
• Prepick, pack, and stage items
• Request, order, and install parts
• Remove parts and process returns
• Track materials by number, work order, bin, and location
• Perform inventory counts

Innovapptive Solution Results & Benefits

With the new mobile solution, implemented by Innovapptive, our customer witnessed several benefits through improving inventory accuracy and visibility, which led to optimized sales planning, thereby increasing revenue through:

• Reduced costs associated with delayed repairs
• Reduced inventory carrying costs
• Shortened or eliminate downtime resulting from part shortages
• Tightened the supply chain, service response times, and ship-to-bill cycles
• Improved workforce safety and productivity
• Improved inventory accuracy while increasing warehouse staff efficiency
• Paper-based processes were eliminated.
• Reduced errors and associated rework.
• Better service levels of maintenance workers
• Increase in overall productivity.
• Better decision making capability.
• Better accuracy of order fulfillment.
• Enhanced and optimized sales planning

For more information related to our SAP Qualified Rapid Deployment Solutions (RDS) for SAP Mobile Platform, Syclo Agentry Platform, Syclo Mobile Apps, SAP Mobile Apps, Fiori and the mPower™ Apps Suite, please contact our team byclicking here.

Appcelerator Cloud Services Impact on Mobile Server-Side Development

The cloud is truly redefining the way we work and play. In it we store our music, our pictures and movies, and our enterprise data. From it we access all of that information from laptops, tablets, smart phones, cars and TVs anywhere anytime. Of course, the mobile revolution is also delivering its fair share of transformation

When we speak with enterprise customers all the time and what we commonly hear goes something like this:

“We have many mobile initiatives and expect to roll out [tens/hundreds/thousands] of apps across multiple platforms over the next few years”

“The apps need to be of high utility and value to our [employees/partners/prospects/customers] and they need to access data from many sources including social networks, public data sources, enterprise data systems like ERP, CRM, SFA, and our custom apps”

“Our competitors have already published something similar, so we need the apps out ASAP”

“But we don’t have the time/money/resources/skills to build all the permutations of mobile client apps as well as the server-side components to support them”

“How can we prioritize one over the other, when we need both. What should we do?”

To answer this question, let me take a slight detour. Remember the good old days of client/server? Life was relatively simple then. We created a database instance with a bunch of tables and fields, hooked it up to a thick client with GUI controls and widgets, and before you knew it, our app was out the door (or more appropriately, on the desk). Network connectivity was not really an issue with LANs and the apps gave us access to the data in an acceptable form factor, on a not-so-portable, big screen, with more than enough room for extras.

But today’s mobile apps are now a complex mash-up of data from many different sources.Today’s apps need to not only look delightful on a multitude of different and smaller-sized screens, but they also need to feel great. They have to support device specific gestures and menus. They have to be cool and engaging. They need to integrate into the user’s life, so they can’t even imagine what it was like before they downloaded it.

In order to do that, an app needs automatic push notifications to update us even when we’re not in the app. We need status updates and feeds from other users so we know what’s happening. We need to “Like” things and share comments so our friends and colleagues know what we’re up to. We want to upload photos so we can share the moments of our lives. Our employees need supply chain data from the SAP system, financial data from the Oracle system and employee data from the HR system, so in that moment of need, in front of a customer or prospect, they can deliver real-time information.

So essentially what we have now are two very different sets of competing requirements – client-side applications and server-side services – both with different success criteria, different development tools and different skill sets.

And therein lies the problem – other than the biggest mega-companies on the planet who don’t have the constraints of money, people, skills, etc, the rest of us are faced with what seems like an impossible predicament.

I would suggest that of the two, the no-brainer winner has to be the client-side app. I don’t think anyone even questions the value of the user experience any more. Look at Apple. They epitomize that maniacal focus in all their products. So too does Google and Amazon.

So that leaves us with the displaced backend server-side. In order to deliver many of the above-mentioned required capabilities, “do-it-yourself” server-side development is perceived as the only solution, where you develop custom software and architectures made up of web, app and database servers to deliver these services and then integrate them to the different client apps. Then you build or provision a new infrastructure to support it all. Then wash, rinse and repeat for every new app and every time one of those data sources changes.

Fortunately there is a way out, and mobile cloud-based services offer a welcome solution. Such backend services provide the core capabilities required, over the cloud, so you can continue to focus on the client-side experience while simply consuming the backend services as needed on the cloud.

At Appcelerator we have Appcelerator Cloud Services (ACS) which offers a fast, easy, and simple way of building next generation mobile apps. With a proven set of ready-to-consume APIs, you can build beautiful apps in a fraction of the time from any mobile toolkit (of course there are numerous benefits if you use Titanium Studio too). ACS is also extensible, so it can integrate with other public services and private corporate apps to shield you from that complexity on the client.

How to migrate app to iOS 7 using Appcelerator

Apple’s recommended steps to update your application to iOS 7. iOS 7 introduces many UI changes, such as borderless buttons, translucent bars and full-screen layout for views.

THINGS EVERY APP MUST DO:

• Update the app icon. In iOS 7, app icons for high-resolution iPhone and iPod touch are 120 x 120 pixels; for high-resolution iPad, app icons are 152 x 152 pixels. (To learn more about all icon sizes, see “Icon and Image Sizes”.) Note that iOS 7 doesn’t apply shine or a drop shadow to the app icon. And, although iOS 7 still applies a mask that rounds the corners of an app icon, it uses a different corner radius than earlier versions of iOS. See the iOS 7 Icons section below.

• Update the launch image to include the status bar area if it doesn’t already do so. This is a difference of 20 pixels in height, that is, the image is stretched 20 more pixels if you do nothing.

• Support Retina display and iPhone 5 in all your artwork and designs, if you’re not already doing so.

• Titanium.UI.iPhone.createNavigationGroup

• Titanium.UI.iPhone.NavigationGroup

• Titanium.UI.iPhone.setStatusBarStyle

• Titanium.UI.iPhone.setStatusBarHidden

• Titanium.UI.iPhone.showStatusBar

• Titanium.UI.iPhone.hideStatusBar

• Titanium.UI.setOrientationModes

How to migrate app to iOS 7 using Appcelerator ?

IOS 7 BEHAVIOR CHANGES:

Button Bar and Tabbed Bar:

On iOS 7, Apple changed the style of segmented controllers, which effects what can be customized for the Button Bar and Tabbed Bar objects in the Titanium SDK. You can no longer set the background color or style of these objects. iOS 7 only supports one style and setting the tint color.

In Release 3.1.3 and later, with iOS 7 and later, when you set the background Color property for these objects, you will be setting the tint color, and the style property is ignored. For iOS 6 and prior, the background Color and style properties still works the same since these are supported on older version of iOS.

Navigation Transitions:

On iOS 7, when transitioning between two windows in a navigation stack, the bottom window slides half way off the screen,  pauses then the top window appears. This is noticeable if you do not specify a background color for your top window, which makes it transparent. As long as you specify a background color for the top window, the application will appear to transition the same as previous iOS versions.

On iOS 6 and earlier, the bottom window would slide off screen as the top window appears on screen at the same time.

Lightweight Windows:

On iOS 7 and later, all lightweight windows, including the first root window, are displayed as full screen with a transparent status bar. Lightweight windows are windows without a navigation controller, that is, not contained in a Navigation Window or Tab Group. Any view objects added to the top of the window appear behind the transparent status bar. If your UI layout relies on the top property, you may need to readjust your layout.

You can also either set the full screen property to true to hide the status bar or set the top property to 20 to move the window below the status bar to compensate for this behavior change.

Status Bar:

In Release 3.1.3 and later, the status bar is controlled by the current window that appears on screen. By default, the status bar is displayed unless you specify the Window’s full screen property to true before opening the window. You can also control the appearance of the status bar using the Window’s status Bar Style property (new API element for Release 3.1.3). These properties can also be set on any top-level container, which include Navigation Window, Split Window and Tab Group objects.

Prior to Release 3.1.3, if you created a full screen window then opened a window without specifying the full screen property. The recently opened window would also appear full screen. In Release 3.1.3 and later, since the default value is to show the status bar, the recently opened window displays.

On iOS 7, the status bar cannot be controlled on the fly with Titanium.UI.iPhone.setStatusBarStyle, Titanium.UI.iPhone.setStatusBarHidden, Titanium.UI.iPhone.showStatusBar or Titanium.UI.iPhone.hideStatusBar. You need to either set the fullscreen property to hide the status bar or statusBarStyle to change the status bar style before opening the window. In Release 3.2.0, you can use the statusBarStyle property to change the status bar style on the fly.

iOS 7 also introduces a new light content status bar style that is exposed as the Titanium.UI.iPhone.StatusBar.LIGHT_CONTENT constant in the Titanium SDK. Use this constant to specify a status bar for use with a dark background. If you want the entire application to use this style, add the following key to your tiapp.xml file.

The following API elements are obsolete or do not work on iOS 7. These elements are deprecated in Release 3.1.3 and removed in Release 3.2.0 except the setter methods.

Android App Development – Java Virtual Machine

What is a Java Virtual Machine?

The Java virtual machine is called “virtual” because it is an abstract computer defined by a specification. To run a Java program, you need a concrete implementation of the abstract specification. This blog describes primarily the abstract specification of the Java virtual machine.

The Lifetime of a Java Virtual Machine

A runtime instance of the Java virtual machine has a clear mission in life: to run one Java application. When a Java application starts, a runtime instance is born. When the application completes, the instance dies. If you start three Java applications at the same time, on the same computer, using the same concrete implementation, you’ll get three Java virtual machine instances. Each Java application runs inside its own Java virtual machine.

A Java virtual machine instance starts running its solitary application by invoking the main() method of some initial class. The main() method must be public, static, return void, and accept one parameter: a String array. Any class with such a main() method can be used as the starting point for a Java application.

For example, consider an application that prints out its command line arguments:

Code:

// On CD-ROM in file jvm/ex1/Echo.java

class Echo {

public static void main(String[] args) {

int len = args.length;

for (int i = 0; i < len; ++i) {

System.out.print(args[i] + " ");

}

System.out.println();

}

}

You must in some implementation-dependent way give a Java virtual machine the name of the initial class that has the main() method that will start the entire application. One real world example of a Java virtual machine implementation is the java program from Sun’s Java 2 SDK. If you wanted to run the Echo application using Sun’s java on Window98, for example, you would type in a command such as:

Java  Echo Greetings, Planet.

The first word in the command, “java,” indicates that the Java virtual machine from Sun’s Java 2 SDK should be run by the operating system. The second word, “Echo,” is the name of the initial class. Echo must have a public static method named main() that returns void and takes a String array as its only parameter. The subsequent words, “Greetings, Planet.,” are the command line arguments for the application. These are passed to the main() method in the String array in the order in which they appear on the command line. So, for the previous example, the contents of the String array passed to main in Echo are: arg[0] is “Greetings,” arg[1] is “Planet.”

The main() method of an application’s initial class serves as the starting point for that application’s initial thread. The initial thread can in turn fire off other threads.

Inside the Java virtual machine, threads come in two flavors: daemon and non- daemon. A daemon thread is ordinarily a thread used by the virtual machine itself, such as a thread that performs garbage collection. The application, however, can mark any threads it creates as daemon threads. The initial thread of an application–the one that begins at main()–is a non- daemon thread.

A Java application continues to execute (the virtual machine instance continues to live) as long as any non-daemon threads are still running. When all non-daemon threads of a Java application terminate, the virtual machine instance will exit. If permitted by the security manager, the application can also cause its own demise by invoking the exit() method of class Runtime or System.

In the Echo application previous, the main() method doesn’t invoke any other threads. After it prints out the command line arguments, main() returns. This terminates the application’s only non-daemon thread, which causes the virtual machine instance to exit.

The Architecture of the Java Virtual Machine

In the Java virtual machine specification, the behavior of a virtual machine instance is described in terms of subsystems, memory areas, data types, and instructions. These components describe an abstract inner architecture for the abstract Java virtual machine. The purpose of these components is not so much to dictate an inner architecture for implementations. It is more to provide a way to strictly define the external behavior of implementations. The specification defines the required behavior of any Java virtual machine implementation in terms of these abstract components and their interactions.

The block diagram of the Java virtual machine that includes the major subsystems and memory areas described in the specification . Each Java virtual machine has a class loader subsystem: a mechanism for loading types (classes and interfaces) given fully qualified names. Each Java virtual machine also has an execution engine: a mechanism responsible for executing the instructions contained in the methods of loaded classes.

When a Java virtual machine runs a program, it needs memory to store many things, including byte codes and other information it extracts from loaded class files, objects the program instantiates, parameters to methods, return values, local variables, and intermediate results of computations. The Java virtual machine organizes the memory it needs to execute a program into several runtime data areas.

Although the same runtime data areas exist in some form in every Java virtual machine implementation, their specification is quite abstract. Many decisions about the structural details of the runtime data areas are left to the designers of individual implementations.

Different implementations of the virtual machine can have very different memory constraints. Some implementations may have a lot of memory in which to work, others may have very little. Some implementations may be able to take advantage of virtual memory, others may not. The abstract nature of the specification of the runtime data areas helps make it easier to implement the Java virtual machine on a wide variety of computers and devices.

Some runtime data areas are shared among all of an application’s threads and others are unique to individual threads. Each instance of the Java virtual machine has one method area and one heap. These areas are shared by all threads running inside the virtual machine. When the virtual machine loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area. As the program runs, the virtual machine places all objects the program instantiates onto the heap .

As each new thread comes into existence, it gets its own pc register (program counter) and Java stack. If the thread is executing a Java method (not a native method), the value of the pc register indicates the next instruction to execute. A thread’s Java stack stores the state of Java (not native) method invocations for the thread. The state of a Java method invocation includes its local variables, the parameters with which it was invoked, its return value (if any), and intermediate calculations. The state of native method invocations is stored in an implementation-dependent way in native method stacks, as well as possibly in registers or other implementation-dependent memory areas.

The Java stack is composed of stack frames (or frames). A stack frame contains the state of one Java method invocation. When a thread invokes a method, the Java virtual machine pushes a new frame onto that thread’s Java stack. When the method completes, the virtual machine pops and discards the frame for that method.

The Java virtual machine has no registers to hold intermediate data values. The instruction set uses the Java stack for storage of intermediate data values. This approach was taken by Java’s designers to keep the Java virtual machine’s instruction set compact and to facilitate implementation on architectures with few or irregular general purpose registers. In addition, the stack-based architecture of the Java virtual machine’s instruction set facilitates the code optimization work done by just-in-time and dynamic compilers that operate at run-time in some virtual machine implementations.

SAP Mobile Platform Licensing – Maximize your ROI

Not knowing the price of mobility can be a BIG problem. Some of the biggest challenges to implementing enterprise mobility solutions are -

• Developing a mobile strategy
• Identifying and prioritizing business cases
• Choosing a platform and mobile technologies
• Budgeting

The choice might be obvious for a lot of SAP’s customer base. With a unified solution offering under the SAP Mobile Platform, enterprises now have access to Sybase Unwired Platform, Syclo, Afaria and Netweaver Gateway. After your enterprise has spent significant resources in nailing down a mobile strategy and choosing a platform, there still are questions around cost. “How much is it going to cost in total?” In order to answer this question it is important to understand the components that make up a typical Mobile App available on the SAP store –

FIRST LAYER—THE BACK-END

SAP customers don’t need to pay additional licensing fees (beyond what they pay for their licenses already) to access the data they’re putting on their mobile devices—regardless of whether that data is in SAP or a non-SAP system.

SECOND LAYER—THE MOBILE PLATFORM

The mobile mid-tier enterprise license includes SAP NetWeaver Gateway,SUP, Afaria and the recent addition of Syclo. SAP offers various pricing options for their mobile platform, depending on the need. It is essential for enterprises to understand these options in order to maximize their investment.

Option 1: The Full License – This is a full use license and is priced per user. With the Full license the user can run any app on the SAP platform from productivity to process apps, custom or partner apps. This is the best choice for users who will use process apps as it will be more cost effective long term by allowing the user to run an unlimited number of apps on the platform. For SAP Mobile platform licensing questions as well as pricing discounts please contact sales@innovapptive.com .

Option 2: Limited Run-time License – It doesn’t make economic sense to invest in Full licenses when a user needs to use a few apps. Rather than purchase a full use license, a runtime license is purchased for each app that the user runs on SAP mobile platform.  The runtime license is priced as a % of the mobile app list price, which is a fraction of the app price. The limited run-time license is available for any SAP mobile app and SAP certified partner apps.

Option 3: Managed Mobility – This is SAP’s version of Enterprise Mobility as a Service (EMaaS). Under this license model service providers will resell the platform as a service to end customers.

THIRD LAYER—THE APPLICATIONS

There are quite a few options available when it comes to sourcing Apps for the enterprise. To see the immediate ROI, you can opt for a few pre-packaged Apps that can be purchased from the SAP Store and they have licensable user-app pricing—ranging from $ 25 to $ 1500.

A key advantage of going with the pre-packaged app is the ability to consume limited run-time licenses. This is a huge cost-savings opportunity. Lets consider the Universal Approval App which lists for $69.99 per user. Cost of licensing this app would be between $7 to $15, depending on the number of licenses. If an enterprise decides to build a similar app in-house the license cost shots up to $1,500 per user license as custom built apps are not eleigible for the limited run-time pricing. Partners will develop most of the mobile apps for SAP—approximately 80 percent of the apps, SAP recently stated.

Finally, SAP and its partners offer Rapid Deployment Services (RDS) for deploying the mobile platform and platform apps. By adhering to a fixed cost, fixed scope and fixed timeline customers are able to see immediate results through a streamlined implementation.

If you would like more information on any of the topics covered here, please email us at sales@innovapptive.com or call us at (713) 300  3762