A single region virtual private network (VPC) created to host DPX application servers across a minimum of 2 (or more) availability zone.

The Hub load balancer’s use path-based routing to send traffic to the correct spoke or the corporate data centre. For example:

Corporate firewall inspecting and validating all API requests for malicious traffic. To achieve high availability a clustered deployment of two or more firewalls should be used.

All API requests made by a Neptune DXP application terminate at the API gateway. For each request, a proxy URL is targeted pointing to the backend application load balancer managing the connections to Neptune DXP microservices. For example, a request to POST Orders may target the /orders resources of a Neptune DXP Order microservice at POST serverscript/orders

A routing function sitting at the edge of the hub network connecting to the data centre through a direct connect provider.

A network connection enabling the routing of traffic from the hub to a spoke. In our example the hub and spokes are in the same region and part of the same AWS account, however, both can vary depending on the complexity of your technical landscape.

Requesting your data centre network. In this case, it is the host to an on-premise SAP installation accessed by Neptune DXP microservices through a secure and private connection implemented using AWS’ Direct Connect service.

A physical or software appliance installed on-premise in your corporate network to receive traffic from Neptune DXP instances through the AWS Direct Connect service.

Installed directly in the SAP Application server(s) to handle API requests received from Neptune DXP instances targeting your SAP system.

In this case, a spoke is created for each operating environment, that is, development, test and production. The composition of each spoke is the same, although it’s likely that the security makeup and data contents found in a production spoke will vary to the non-production spoke networks.

The spoke load balancer distributes traffic to the Neptune DXP application servers.

A more agile arrangement taking advantage of Neptune DXPs pre-packaged deployment in a Docker image is in adopting a Kubernetes orchestration solution deployed as a cloud service to organise the delivery of both Neptune DXP application server and microservice instances. In this case, we utilise AWS’s Elastic Kubernetes Service (EKS).

The Neptune DXP application server is the most important workload in this stack. As it must be highly available new instances will be “spun-up” and “terminated” based on demand and ad-hoc failures. To avoid the manual setup of each new instance we must register our Neptune DXP configuration inside a Docker container image with an AWS elastic container registry service. When a new instance is the required the EKS will reference the registry and retrieve our Neptune DXP container image.

Dynamically auto-scaled Neptune DXP app servers and microservice instances spun up by the elastic Kubernetes service.

Used as the identity provider for Neptune DXP corporate users and resources. Neptune DXP can be configured to delegate the validation of a user’s credentials to the active directory service and issue Neptune DXP with a token to avoid re-sending the user’s credentials with each request.

Used to mount a file system to a Neptune DXP instance to enable the download of NPM packages and their associated files. As Neptune DXP instances can be implemented as separate versions of the same NPM packages it is recommended that each Neptune DXP instance segregates access to a file system rather than share the same locations with other services. This avoids coupling and dependency issues that emerge when shared packages are upgraded by one service but not required so by another.

Enabling the configuration of Neptune DXP instances with access to a mail (SMTP) services to generate email messages.