LEAP

Leap is our application architecture and deployment framework. See What’s New

Leap Core

As Leap gets into more implementers’ hands we took some feedback regarding creating 1) better performance and 2) a more consistent and usable execution lifecycle. A great deal of work was spent on ‘cleaning up’ the flow and streamlining it. Additionally, we saw the need to add additional handlers in the area of Implementation selection (a feature allowing us to dynamically choose an implementation). This is a very important feature for implementers operating in multi-vendor sites. See the Execution Lifecycle below:

Leap Entities

Data acquisition, and some of the associated data actions, is core to any system. Many systems permit minor flow changes with table settings, configurations, and exit points. However, changing settings, policies, and configuration only gets you so far. Sometimes, you might just need to get access to some additional bit of data to avoid a lot of extra keystrokes on the floor. So, being able to create abstract entities, even entities exposed from other systems, and augment or reshape them can produce more desirable results in a system.

A new feature to the Leap Framework, called Leap Entities, provides a whole new set of capabilities in this regard. Leap Entities permit you to define an abstract, vendor aware, entity (data item or action) which has some defined attributes:

Taxonomy. This is the lingua franca the system with which you are communicating – a way to describe data (what data is called and how to reference it). It supports the definition of a base Taxonomy, say for BlueYonder 2019.1 it might be called BY2019, and any number of foreign (vendor or system) taxonomies. BY2019 calls the pick identifier a wrkref while another system might call it PickID. Our XML-based taxonomy definitions provide a means of understanding the basic ways disparate systems reference similar data.
Projection. Where the taxonomy tells us how to describe data, the projection tells us how to form the data – the format of data payloads. The days of flat structures ended with the introduction of XML and have been further deprecated by the popularity of formats like JSON. Both payload formats permit convenient and ubiquitous ways of defining and communicating complex objects. The XML-Based projection definition provides a roadmap for the Leap Architecture to create complex object payloads on the fly.
Transformation. From an integration perspective, a big part of mediating the interchange of data between systems is handling the “getting from here-to-there” problem. In other words, how do you take on the actual transformation? With the taxonomy and the format of the payload defined (the projection) – the last step is the actual transformation. In most systems, these 3 elements (especially transformation) are external to the architecture. They would require an external system like Mulesoft or WebMethods to take care of this step. This is NOT the case in the Leap, Always Integrating, architecture. In this architecture, the transformation step is just another configuration, performed in-line during service execution. It permits the definition of custom transformation adaptors or the use of XSLT. Thus, the necessity of an external integration tool or framework is largely eliminated.

Below is an example of the Entity configuration for a data service for interfacing with robots. The base taxonomy is BY2019 Warehouse Management System, and the destinations are Locus Robotics and 6 River Systems. Note the highlighted differences in the configuration: TransformationConfiguration, ProjectionFileName (both extracted from a Swagger file), and a TaxonomyFileName.

Locus Robotics
Entity Configuration:

6 River Systems Robotics
Entity Configuration:

See a short view of doing
a codelsss integration
to these two vendors
in the video below.

Super Entities

As we were developing our entity framework, we found that not all vendors had their APIs completely fleshed out, had implemented important variations with custom filters or ODATA queries, or were just missing important elements. To handle this, we create the idea of a Super Entity. This is a concept like a Superclass in object-oriented programming. We can abstractly redefine the Entity via configuration. This permits us to retrieve data from multiple services, or even multiple disparate systems and return the data in a single entity request. Once again, this uses the core capabilities of the Leap architecture to define, in XML content, a set of flows that are bound under one Super entity.

Leap Execution Activity Framework (LEAF)

The Leap Execution Activity Framework (or LEAF) provides the framework for a distributed, cloud/hybrid, multi-site, activity-based coordination, and streaming processing. LEAF allows you to define the activities, but not necessarily how they will be accomplished; to define the requirements of an action or activity without knowing who or what will execute it.

We started thinking about this idea about 3 years ago as we were helping one of our software partners abstract robotics and machine/human interaction for automation. Very tactical, specific, and proprietary software packages, generally called Warehouse Execution Systems (WES) have been doing some of this work since the 1990s. But to them, everything seemed like a new problem, one which they have to create integrations for – almost as if starting from scratch with each new system.

Frankly, it seems a fruitless effort to just consider this an interface problem without addressing the coordination challenges these sorts of systems, inevitably, face. So, we came up with a strategy for modeling interactions instead of interfaces to de-couple the functional/coordination challenges from any specific technology. The idea of creating a set of general, reusable services, to coordinate the execution and aggregation of activities, emerged. We call this concept Execution Activity Stream (EAS) systems.

Using the concept of Actors, Activities, and abstract data elements, an EAS-based System would contain an extensible set of verbs and the payload that describe activities and observations.

Using LEAF you can create the verbs within an EAS-based system to:

  1. Construct an on-prem or cloud/hybrid WES for single-site or multi-site operations.
  2. Construct an automated Task Managing system (Distributed Work Manager) that includes both humans and robots. It could further take guidance from Machine Learn/AI systems to alter priorities or change the actors involved from humans to robots to some other hardware automatically.
  3. Direct picking to Pick-to-light, Good-to-Person, robotic co-picking bots, or plain-old humans and record all necessary observations along the way (travel start, travel end, verification complete, etc).
  4. Conduct cases on a conveyor and record the movements (divert confirms).
  5. Guide trailer movements in the yard and record placement. Or, in an RFID-enabled yard, pick up any trailer position observations during yard jockey movements.
  6. Support gamified applications by allowing for activity injection and dynamic groupings with goals.
  7. Constantly feed WorkForce Management (WFM) systems for labor data and the predictive shifting of resources.
  8. Support stream-queries to feed Machine Learning and AI systems.

The basic flow of LEAF is shown below: