jmix-framework / jmix-bookstore Goto Github PK

One example of a BPMN Process can be the actual shipment of the order. It is quite easy to understand that this is a long-running process which aligns well with the nature of BPMN solutions.

The business process would go like this:

• An order is placed by the by a order fulfillment specialist
• Orders above 200 $ are reviewed by the backoffice agent's supervisor
• For Orders above 1000 $, the Sales representative will be information through notifications
• Once the order is confirmed, the shipment will be prepared
• The packaging is performed by the fulfilment department (manual task for shipment list & acknowledgement)
• Shipment company informed via external HTTP interaction

Open Questions

• ability to enter shipping address during order creation
• proper order line edit screen
• proper alignment on smaller screens

env
display 1920x1080
chrome browser

TC
Open project
Pay attention to the section of the screen with user authorization data
Select menu item:

AR

Orders - the section has moved to the right
HR - Users
BPM - Start process
BPM - Decision table modeler - the section has moved to the right
Reports - Reports
Reports - Reports - Reports
Reports - Run reports
Administrators - Resource roles
Administrators - Row-level roles
Administrators - Tenants
Administrators - Notifications
Administrators - Quartz jobs

Even on the maximum screen width.

Here the idea is that we notify the order fulfillment employees when a shipment has been delivered (order fulfilled). This would work nicely together with the BPM process #2 and the maps UI to visualise the order fulfilment.

It requires some "fakings" though. Somehow we need to after a particular period of time trigger some action that represents the order being fulfilled. Perhaps it is possible to do it as part of the BPM process #2 and use the scheduling capabilities from flowable there. It also requires to somehow emulate the shipment company actor with some code that makes random decisions like acknowledging an order, or return that an order could not be fulfilled.

One use-case for a business calender could be to model out the holidays for the business. This could be used for e.g. calculating / considering the shipment dates during the order fulfillment.

Open Questions

When an order is placed manually by the order fulfillment person, the sales employee that is responsible for this territory should be notified about the order placement.

This does not need to happen through a BPM process, but should use regular entity events mechanism.

Currently the width of the available space is not correctly calculated. This leads to the situation, that oftentimes the end of the table component and also the logout button disappear on the right of the screen. Also it creates a "flickering" when going from screen to screen.

See: https://demo.jmix.io/bookstore/

On different screen sizes the problem occurs more / less often.

The cause for this situation might be the custom top bar containing the logout button, the username, the tenant etc.

• the sales employees should only be exposed to the customers & orders in their corresponding territory
• the order fulfillment employees should be limited to the customers & orders in their corresponding territory

It slows down startup.
Check if some data already exists in the database or introduce a property to bypass this process.

TC

Set sity on Customer screen -> OK
Open the user card again
Change sity on Customer screen
Click

AR

Point on the map stays the same

and linking to the city on the screen Employee does not work

We want to show the Maps component and visualise the Customer Location as well as some visualisation where the book package is currently located (if possible).

This should show the capabilities of the Maps addon quite well.

For that we need to extend the domain model in the following ways:

1. Fulfillment Center Entity (which contains an Address to put it on the Map)
2. Order has a property fulfilledBy or deliveredFrom referencing the distribution center

The point of travel for the packet is randomly calculated by picking on points in between start / end and putting a driver icon on it.

The accuracy of the route should be based on the zoom level. To render a fast route, the parameter overview for the Routing API should be set to simplified. Once a particular zoom level is reached, a recalculation with value full should be performed. Zoom Level changes can be recognised via GeoMap::addZoomEndListener(Consumer<ZoomEndEvent> listener).

• proper alignment on smaller screens

set up regular audit log settings for all relevant entities