GB2616060A - Improved enterprise resource planning platform - Google Patents

Abstract

An improved Enterprise Resource Planning ERP platform 100 provides a first set of services layer configured to provide a first set of core services 109 and a second services layer configured to provide a plurality of third party interface 110,111,112 microservices, each of which provides an interface dedicated to one third party 300,310,320 . The platform can be used as a multi-carrier shipping platform to easily integrate and update functionality to different shipping carriers. Managing plural different shipping carriers necessitates the use of plural software platforms corresponding to each carrier. The layered approach proposed enables integration of new or updated functionality from third party carriers.

Description

Improved Enterprise Resource Planning Platform The present disclosure relates to enterprise resource planning (ERP) platforms and in particular, but not exclusively, to an improved multi-carrier shipping platform, including systems and methods for implementing the same.

ERP is the integrated management of business processes and relies on multiple technologies implemented in software and hardware. One key element of ERP is supply chain management and, in particular, shipping and logistics.

Movement of goods is a complex logistical operation involving many cooperating parties. If an enterprise wishes to transport goods to another party, such as a retailer or an end customer, they typically use the services of a shipping carrier. The shipping carrier provides fulfilment operations that help with collection and delivery of goods, along with logistical operations including managing consignment manifests, tracking shipments, billing and managing returns.

A small enterprise may conceivably use a single carrier to provide all of its shipping services, but larger enterprises typically rely on using multiple different carriers to take into account different capabilities, geographic reach, pricing structures, service level agreements and so on.

Managing multiple carriers necessitates use of multiple different platforms, as each carrier has their own proprietary system and software platform. This is complex, and so various attempts have been made to integrate multiple carriers into a single platform for use by large enterprises that need to engage with multiple carriers.

In the present description, the term "shipping" will be used as a general term for the transportation of one or more physical items. This can be by any distribution method including by road, train, air, or sea and can include movement of parcels and freight. A consignment is one or more packages or parcels which are intended for delivery to a particular recipient. A consignment, also called a shipment, may include multiple packets including mail, parcels, pallets, or containers. Supply chains can be complex and involve many parties such as manufacturers, distributors, importers, exporters, wholesalers, retailers and corporate or private customers.

In general, we will refer herein to a sender as a party that initiates the transportation of a consignment, a recipient as a party that receives a consignment, and a carrier that provides services to deliver goods from the sender to the recipient. The recipient may request goods from the sender (for example by placing an online order) and the sender will engage the services of the carrier to fulfil the order. In the case of items being returned, the original recipient will then become the sender. In practice, there will be a complex supply chain of multiple third parties between sender and recipient, so there may be more than one "carrier" and various parties that provide other services such as import and export formalities, sea or rail transport, invoicing, order tracking and so on. Where a single carrier is used for fulfilment, they may themselves sub-contract to other parties to fulfil different component parts of the supply chain which are involved in the successful delivery of a consignment.

Various sophisticated technologies have been developed to manage supply chains and manage the logistics of shipping. Through the use of various internet technologies sophisticated tracking of parcel delivery is possible and other functions such as label printing and ordering can be achieved online.

Existing multi-carrier shipping platforms may in particular use a service-oriented architecture (S0A) in order to integrate different systems and to cope with different data 25 formats.

Standard existing practice is to develop carrier specific code modules in such a way that they present a standard interface to a multi-carrier shipping platform, adopting a "plug-in" style approach. This means that building in a new carrier means rebuilding the main shipping platform code to recognise and use the new plugin for the new carrier. To do this, the code for the platform must be re-compiled and then tested and re-deployed as a new executable with the new "plugin" now incorporated, with the platform code being modified to function with the new plugin. Bringing in a new carrier therefore involves a complex software development process and involves modifying the main central system of the platform. Additionally, where an existing carrier plugin has to be changed to a new version, a rebuild of a similar nature is also required.

There is a large ecosystem of shipping and carrier providers, whose systems are always evolving. Therefore, there is a need to provide a multi-carrier shipping platform that enables swift integration of new carriers, or that can cope easily with updates to carrier systems.

There is a similar need in general for enterprise resource planning applications to be able to seamlessly integrate new or updated functionality provided by third party providers.

SUMMARY

According to a first aspect of the disclosure, there is provided a computer-implemented system arranged to implement a set of services and comprising: a first services layer configured to provide a first set of core services; and a second services layer configured to provide a plurality of third party interface microservices, each of which provides an interface dedicated to one third party.

Optionally, the third party interface microservices comprise a plurality of endpoints, each for implementing one of the set of services being provided by the system.

Optionally, the services are implemented by the combination of core services and microservices.

Optionally, the core services are implemented as web services.

Optionally, the first services layer is configured to exchange requests with the second services layer, and to transform the requests between a first format comprising a generic data structure and a second format comprising a data structure specific to a particular third party.

Optionally, the system comprises a configuration data store and the first services layer is arranged to, upon receiving a request specifying a particular third party, load a configuration from the configuration store related to said third party and to use said configuration to transform the request to the second data format.

Optionally, the second services layer is arranged to exchange requests with the first services layer and to transform the requests between said first and second formats.

Optionally, the set of services comprises shipping functions.

Optionally, the first services layer comprises one or more of service availability, booking, and voiding; and the second services layer comprises one or more of: manifesting and tracking.

According to a second aspect of the disclosure, there is provided a method of providing computer-implemented services, comprising: providing a first set of core services in a first services layer; and providing a plurality of third party interface microservices in a second services layer, wherein each of said third party interface microservices provides an interface dedicated to one third party.

The method of the second aspect may also comprise providing and/or using the apparatus of the first aspect, and contain steps as disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

S

Figure 1 illustrates an overview of the parties that interact with a multi carrier shipping platform as an example clan enterprise resource planning application; Figure 2 illustrates the systems architecture involved in a shipping operation and including a

platform according to the disclosure;

Figure 3 illustrates components of a platform according to an aspect of the disclosure; Figure 4 illustrates the structure of a computer system which may be used as a component

part of the platform of the disclosure;

Figure 5 shows an overview of a multi-carrier shipping platform; Figure 6 illustrates aspects of the operation of booking, voiding and service availability functions of the platform of Figure 5; Figure 7 illustrates aspects of the operation of an electronic manifest submission function of the platform of Figure 5; and Figure 8 illustrates aspects of the operation of order tracking functions of the platform of Figure 5.

DETAILED DESCRIPTION

It is known to implement software for business processes in a service oriented architecture (S0A). A service is a discreet unit of functionality that can be accessed remotely and acted upon and updated independently. A service logically represents a repeatable business activity with a specified outcome. It is a "black box" for its consumers, meaning that another service or person who requests it does not have to be aware of the service's inner workings. In this way, service oriented architecture provides modularity of services, and one service being updated does not affect the other services because they just rely upon its inputs and outputs.

A variation of a service oriented architecture is a microservices architecture, where an application is arranged as a collection of loosely coupled services which are fine grained and which typically employ lightweight protocols. A microservice is typically more fine-grained than what may be typically deployed as a service in a general service-oriented architecture. The benefits of decomposing an application into different smaller services are numerous, but include modularity, scalability, integration of heterogeneous and legacy systems and distributed development. Microservices can be implemented in many different programming languages and might use different infrastructures.

Implementers commonly build SOAs using web services standards or specifications such as SOAP (Simple Object Access Protocol), which provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, also implement SOA using any other service-based technology, such as Jini, CORBA, Internet Communications Engine, REST, or gRPC.

This disclosure provides systems and methodologies which implement business processes using a first layer of common core services and a second layer of microservices, where each microservice provides functionality associated with a third party entity such as a vendor or carrier.

The systems and methods of the disclosure also allow interfaces for communication with third parties' platforms to be added seamlessly, without requiring the central platform to be rebuilt. Implementation details specific to third parties (such as carriers) are fully isolated in a standalone deployable form that is itself scalable, testable, redundant, and offers high availability.

A single microservice is dedicated to one third party and comprises a plurality of endpoints (such as SOAP or REST/JSON API endpoints, or other HTTP web API endpoints), each of which are associated with a service provided by the platform. The interaction of a third party with the platform may be governed exclusively by these dedicated microservices. Normally a single microservice will take care of the implementation details for a single third party, although it is possible that there could be more than one microservice provided for a specific third party if its needs are unusually complex.

The platform may also provide other microservices that provide more traditional atomic services (such as new user registration, user profile management) which can be combined with the third-party interface microservices and other common core services for the fulfilment of a business process.

In an example, the disclosure can provide a central common shipping platform and the third party interface microservices comprise a plurality of carrier microservices, each forming the interface to external third party shipping suppliers.

Each carrier microservice provides the same callable endpoints for different carrier functions, including one or more of: * Service availability: determining what services can be offered * Booking: confirming the selection of a service and returning a shipping label * Voiding: cancelling a booked shipment with a carrier before collection * Manifesting: Producing an electronic manifest confirming the orders to be shipped on a specific day * Tracking: Retrieving tracking information on the progress of a shipment to final delivery.

This list of carrier functions is not exhaustive, and it will be appreciated that the principles of the disclosure can be applied to any other business function inherent in interacting with a carrier, such as tracking or reporting on CO2 emissions associated with a shipment, or reporting on any other parameter.

Addition of a new carrier to the shipping platform only requires the implementation of a new microservice specific to that carrier, and through data configuration the specification of the URL endpoints to call for each of the carrier functions. Wide technical and procedural variation between carriers is "hidden" within the microservice implementations.

Figure 1 illustrates an overview of the parties that interact with a multi-carrier shipping platform 100, as an example of an enterprise resource planning application. The platform may be used by various parties including a manufacturer 102, a carrier 104, a commercial customer 106 or a private customer 108. Each of the parties may interact with the platform 100 via suitable communication links. Customers 106, 108 may also interact directly with each other or with the carrier 104. It is to be appreciated that this diagram does not show all the parties that may be involved in a supply chain. For example, other parties that may interact with the platform 100 include importers and exporters, transport companies, accounting and billing companies, and the platform 100 is designed to work with multiple carriers, being able to cooperate with a large number of carriers.

Figure 2 shows an illustration of an architecture for providing the platform. The platform is provided remotely from other systems, via a cloud or other networked connection. The other systems may for example include a commercial party's ERP system, a commercial party's warehouse IT equipment (including handheld devices, scanners, PCs, label printers, weighing scales), a commercial party's customer service department users (PCs or mobile devices), an individual customer's PC or mobile device, a plurality of separate carrier shipping interfaces such as APIs.

Figure 3 shows the components of a platform according to an aspect of the disclosure. The multi-carrier platform 100 may include components that provide services for booking, voiding, providing service availability, submitting electronic manifests and tracking. This list is non-exhaustive. In the illustration, the platform 100 comprises a set of core services 109 which provide interfaces 110, 111, 112, which interact with respective carriers 300, 310, 320 via their respective endpoints 301-303, 311-313 and 321-323. A carrier system comprises an interface for connection with external parties such as the platform or with users, and may also expose an API, electronic data interchange (EDI) or other type of interface. The carrier system 300 may present one or more endpoints such as an endpoint to determine service availability, an endpoint to take in a booking and return a label, an endpoint to allow a previous made booking to be cancelled (voided), an endpoint to submit an electronic manifest, or an endpoint to perform tracking queries.

These interfaces may offer real-time functionality, but this is not essential. For example, a file based "[Dl" (Electronic Data Interchange) mechanism can enable a service request such as a booking to be transmitted as a file retrospectively at the end of the day, summarising the details of all jobs booked during that day.

The present disclosure provides a system of networked computers running services which can be selectively executed, queried and controlled to orchestrate and control the movement of goods in a supply chain. The services are implemented as processes executed by one or many threads.

The core services and microservices can be distributed across different physical nodes. All services can be individually addressable by a URL, which means that the name or IP address of the machine they are on is an inherent part of their address, plus a name or "folder" within that machine. Subject to security being applied (i.e. authentication credentials) the services can reside anywhere on the internet relative to each other and still communicate.

Alternatively, the platform may if desired comprise a computing device that implements both common core services and third party interface microservices. The computing device can instantiate a process executed by one or many threads that calls one or more of the core services and one or more of the third party interface microservices to enable a functionality to be implemented.

Figure 4 illustrates the structure of a computer system. A plurality of such computing devices can form component parts of the present invention. The computer system 400 comprises a module 402 which is configured to provide functionality of the platform 100. The computer system 400 may comprise a processor 404, a storage device 406, RAM 408, ROM 410, a data interface 412, a communications interface 414, a display 416, and an input device 418. The computer system 400 may comprise a bus 420 to enable communication between the different components.

The computer system 400 may be configured to load an application. The instructions provided by the application may be carried out by the processor 404. The application may comprise components for implement the multi-carrier shipping platform 100. A user may interact with the computer system 400 using the display 416 and the input device 418 to instruct the computer system 400 to implement the methods of the present disclosure.

Figure 5 illustrates an overview of a platform 100 in accordance with an embodiment of the present disclosure, showing selected components. The platform provides a common carrier web service 500 and a plurality of carrier microservices 502. One carrier microservice 502 is provided for each carrier, and each comprises a plurality of endpoints for the functions of the business process.

The carrier microservices 502 can interact with a third party carrier application programming interface (API) 508 which is outside of the platform. The common carrier web service may receive a service availability request 510 and/or booking request 512, which it can then forward (514) to the appropriate carrier microservice 502. The platform 100 also provides a manifesting engine 504 which may make a request to manifest (confirm) the order at a configurable time or time interval, and a tracking engine 506 which may automatically periodically request tracking information from the appropriate carrier microservice 502 and update it as appropriate.

The common carrier web service 500 may be an HTTP web service that abstracts and provides access to a first subset of carrier operations, which may be service availability booking and voiding. The manifesting engine 504 may comprise a scheduled function that instructs carrier microservices to submit electronic manifests and the tracking engine 506 may comprise a scheduled function that retrieves and update shipment tracking progress. In a preferred embodiment, each carrier microservice may expose some of the following operations: service availability, booking, voiding, tracking and manifesting.

Each of the processes driven by carrier microservices 502 and can be removed, added or swapped without having to build or redeploy the common carrier web service tracking engine 506 or manifesting engine 504. Communication with a third party carrier is marshalled by the corresponding carrier microservice 502.

When a new third party is to be added to the system, then a new microservice 502 is written. For each function, a data mapping is made between the common core webservices and the microservice endpoint. If the third party implements a given function in a manner that is identical to the common core service, then the data mapping can be a simple one-to-one mapping. However, variations can still be taken account of with a data mapping, so that if a given third party implements the function in a non-standard or unusual way, this can still be accommodated. A set of functions is identified as common or fundamental and provided as common core services, so that the amount of custom coding involved when providing a third party interface microservice is reduced.

Figure 6 shows aspects of the common carrier web service 500 of figure 5. In this preferred embodiment, this web service 500 provides booking, voiding and service availability operations that can be performed against third party carriers. First at step 600, a request is made to the common carrier web service 500 which specifies a carrier. The request may be a service availability request, a booking request or a voiding request sent via HTTP or equivalent protocol. The common carrier web service 500 then sends a query 602 to a carrier microservice configuration data store 604. The configuration is loaded for the appropriate microservice 502 and is retrieved from the configuration data store 604. Next, the common carrier web service 500 makes an HTTP request 606 against a specific carrier microservice 502 using a generic request structure. The carrier microservice 502 receives the request and marshals the generic request to one appropriate for the third party carrier API 508 (step 608). The response returned by the third party carrier API 508 is then marshalled into a generic structure and is returned to the common carrier web service SOO by the carrier microservice 502, after which the generic structure is returned to the caller who made the original request 600 either confirming or disconfirming the operation, namely the service availability, the booking or the voiding request in this example.

Figure 7 illustrates aspects of submitting electronic manifests using the manifesting engine 504 of figure 5. As can be seen here, the manifesting engine 504 comprises a manifest trigger function 700 and a manifesting function 702. The manifesting engine 504 is responsible for producing an electronic manifest which confirms orders to be shipped on a given day. This component uses configuration to drive the time of day the manifest runs for individual carrier accounts. The manifesting trigger function 700 runs regularly and queues instructions to create electronic manifests when a specified time of day is reached for a given account. When the manifest trigger function 700 runs, it queries a manifest trigger configuration store 704 to identify any electronic manifests due to be submitted. The manifesting engine 504 runs continuously taking the next available manifest instruction from the queue. Instructions are added to a manifest instruction queue 706, shown here as a memory buffer. The manifesting function 702 then queries an orders database 708 and carrier microservice configuration data store 604 to retrieve unique identifiers such as tracking numbers for shipments due to be manifested that day. The configuration specific to an appropriate microservice 502 depending on the specified carrier is loaded from the store 604 and this information is combined to form a generic request structure sent to the correct carrier microservice 502 over HTTP. The generic request structure is used to create an electronic manifest and forward it to the carrier. In this example, using the third party carrier API 508. Once complete, the microservice 502 returns a generic response structure to the manifesting function 702 which marks the instruction as complete and sends an update to the manifesting trigger function 700 or to the manifest trigger configuration store 604 to remove it from the list of manifests to be submitted.

If the above process fails for some reason, then the entire process will retry for a set number of times up until a configurable limit. If the process fails to successfully complete within said limit, a notification is sent to notify an administrator.

Figure 8 illustrates a process of updating tracking using the tracking engine 506 of the embodiment shown in figure 5.

The tracking engine is responsible for retrieving the tracking information on a regular schedule for in progress shipments. This component uses configurable schedules which are specified for each carrier for which tracking progress is retrieved. The schedules may be, for example, updated every 15 minutes or some other regular interval. The tracking trigger function 800 queries a tracking trigger configuration store 804 to retrieve carrier tracking schedules. Then, according to the schedules, instructions to retrieve tracking information for specific carriers are added to a tracking instruction queue 806 and are picked up for processing by the tracking function 802, preferably on a first in, first out basis. The tracking function 802 runs continuously taking the next available tracking instruction from the queue. The tracking function retrieves tracking numbers for shipments due to be manifested from the orders database 808 and, depending on the specified carrier, a configuration is loaded for the appropriate microservice from the carrier microservice configuration data store 604. The tracking number and configuration data are combined to create a generic request structure sent over HTTP and made against a carrier microservice 502 using the generic request structure. This is then used to retrieve information from the carrier, typically via a third party carrier API 508. It is noted that technologies may vary between carriers, for example, FTP servers or other technical means may be employed to provide tracking information to the platform. The microservice 502 then returns a generic response structure to the tracking function 802, which includes tracking information for all shipments specified in the request. The tracking function 802 then creates and/or updates shipment progress records in the orders database 808.

The invention provides various advantages. Providing third party compatibility with microservices, and preferably using microservice with multiple endpoints, provides great flexibility, as traditionally microservices are purely provided on a more atomic basis for functions such as new user registration, user profile management or dealing with specific individual requests or other atomic tasks.

In addition, having a microservice which is specific to one particular third party is not known. Each of the plurality of the third party interface microservices may have a similar set of functions (such as manifesting, tracking), but multiple such microservices are provided, each being dedicated to a specific third party (e.g. carrier), which have the details of each function specifically tailored for that third party's systems. This is different from a normal arrangement, where a microservice is associated with a particular technical function and is designed to be used by the entire system.

Furthermore, generalising a specific function to be provided as a core common service means that the complexity of designing and deploying microservices is reduced. Also, because the deployment of a new microservice does not rely on the entire system being rebuilt, additions and changes can be made without requiring the system to be brought offline, which helps increase uptime and general reliability for users of the shipping platform.

Various improvements and modifications could be made to the above without departing from the scope of the disclosure. In particular, while specific reference to a shipping platform has been mentioned in the embodiments listed above, it will be appreciated that the principles of the invention may be applied to other enterprise resource planning or other areas of endeavour and the scope of the invention should be determined by appropriate reference to the claims.

Claims (10)

1. CLAIMS1. A computer-implemented system arranged to implement a set of services and comprising: a first services layer configured to provide a first set of core services; and a second services layer configured to provide a plurality of third party interface microservices, each of which provides an interface dedicated to one third party.
2. 2. The system of claim 1, wherein the third party interface microservices comprise a plurality of endpoints, each for implementing one of the set of services being provided by the system.
3. 3. The system of claim 1 or claim 2, wherein the services are implemented by the combination of core services and microservices.
4. 4. The system of any preceding claim, wherein the core services are implemented as web services.
5. 5. The system of any preceding claim, wherein the first services layer is configured to exchange requests with the second services layer, and to transform the requests between a first format comprising a generic data structure and a second format comprising a data structure specific to a particular third party.
6. 6. The system of claim 5, comprising a configuration data store and wherein the first services layer is arranged to, upon receiving a request specifying a particular third party, load a configuration from the configuration store related to said third party and to use said configuration to transform the request to the second data format.
7. 7. The system of claims or claim 6, wherein the second services layer is arranged to exchange requests with the first services layer and to transform the requests between said first and second formats.
8. 8. The system of any preceding claim, wherein the set of services comprises shipping functions.
9. 9. The system of claim and the first services layer comprises one or more of service availability, booking, and voiding; and the second services layer comprises one or more of: manifesting and tracking.
10. 10. A method of providing computer-implemented services, comprising: providing a first set of core services in a first services layer; and providing a plurality of third party interface microservices in a second services layer, wherein each of said third party interface microservices provides an interface dedicated to one third party.