Leap CoreAs 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:
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:
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.
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:
The basic flow of LEAF is shown below: