Logistics often focuses on minimizing the costs over several processes. In this branch process optimization and cost reducing methods like two-stage order- picking are common. This method separates the order-picking-process into two different sub-processes. During thefirst sub-process all articles for all orders are collected from the stock. In the second step, all articles need to be separated and attached to the given orders.
The Logistics branch requires highly available and easy to use software solutions to resolve complex process chains. The additional requirement is an open interface structure to allow partner companies to exchange data. Furthermore, the logistics companies depend on efficient and stable workflows which need to support by
flexible software solutions to resolve the new workflows or process changes. In general, within a cloud process three different kinds of tasks can be distin- guished. Thefirst is a converter service for the integration of external systems. All external systems have their own data structure and are only able to communicate with general data specification within the logistics domain, like EDIFACT [4]. This data has to be converted between the given specification and the Logistics Mall internal business objects (BO) in both ways of communication. The BOs are logistics domain specific objects, like a picking list or a handling unit (HU). The BOs are transport objects, which allow the transport of data in-between the running application or between different apps. For each required data specification a single converter app is required related to the one app one function principle. Integration of external data is needed to migrate existing data into the cloud environment and to connect cloud services with systems hosted on premise. These services are executed
autonomously. The second service kind is for executing autonomous business functions like calculations and does not require user interactions. Those functions are common in the logistics domain. Finally the third service kind is for providing a user interface. For each of these kinds a special type of app is defined. The three apps, converter-, service-, and end-user-apps, are described in detail in chapter“Empirical Qualitative Analysis of the Current Cloud Computing Market for Logistics”.
For all these kinds a dedicated Business App has to be developed. The“one App one business function” principle as mentioned in chapter “Logistics Software Systems and Functions: An Overview of ERP, WMS, TMS and SCM Systems”
addresses the continually changing requirements of the logistics domain. If the customer’s requirements have changed, a process could be easily adjusted by removing, replacing or adding different apps. Another benefit of this granular approach is that a customer has to pay only for functionality that is really needed and executed. Furthermore, this rule may leads to small services, which are easier to monitor and to manage as complex services with multiple functions. Additionally, these small services can be exchanged with other services in a running process.
Due to the Service-oriented approach Business Apps are loosely coupled and should have no knowledge about other services or environment specifics. They have to provide an interface that is able to accept Business Object Documents (BOD) and to send BODs to the Process Engine’s Message Broker. A BOD can be described as an envelope that contains a list of BO instances of one type. The BOD itself contains information about the origin of the BOD. BODs that are exchanged with the Process Engine are only containing BO instance IDs. The BO instance details have to be read from the BO Instance Repository by the App themselves. The Broker is defined as central bus infrastructure for communicating between Logistics Mall environment1 essentials. Furthermore, Apps have to request the required BO instances, which are presented by their IDs within the BOD, from the BO Instance Repository. These three ways of communication must be provided and implemented by each Business App that should be executed within the Logistics Mall Cloud environment.
The Business App architecture should also be technology neutral to enable the adaption of already existing IT services for the Logistics Mall. Those services are based on several technologies. The lowest standardized common denominator of in the Logistics Mall is used by the environment. The communication infrastructure should be designed with widely accepted standards as defined by [2]. This enables a wide range of technologies a Business App could be developed with.
3 Logistics Mall Specifics Requirements
In this chapter requirements of other Logistics Mall components are described. The focus is here mainly on the process engine that interacts as mentioned before with the apps.
The process engine is not able to differentiate between App types. Additionally, the Business Object Instance Repository is not able to lock BO instances due to its client wide usage. Further, the repository does not have any knowledge about Apps or other clients, like the process engine. It is just a system wide data storage approach. To consider this issue, End-user Apps have to provide a mechanism to store incoming BOs until a user completely processed it. This mechanism has to avoid errors due to parallel processing of one BO. A BO has to be locked directly, if a user started to process it.