I read the following question and the proposed solution:
Immovable planning entities for chained entities
In our problem we would like to send a set of technicians and customer with their appointment windows to optaplanner with the following condition:
Some customers were already served or are being served, so all of them are already belonging to a certain technician who did (is doing) the work there.
It is similar to the following example:
I start the time dependent vehicle routing example and stop it far before the "best" solution is obtained.
Then I want to use this solution as input, whereby from each technician in the simplest case only the very first customer of the chain has to be set immovable (because he was already served), but all the others are still available for the rest optimization.
In the 6.2 reference manual, take a look at:
immovable planning entities: don't change the entities which are already assigned (= by locking them)
non-volatile replanning: prefer not to change the entities which are already assigned, unless the gain is worth it
Related
All e-mail templates in Shopware 6 reference the transactions payment name and current state by using the first collection entry order.transactions.first.paymentMethod.translated.name and
order.transactions.first.stateMachineState.translated.name.
Is the transaction sorting for e-mails different that the default sorting by createdAt?
Because according to all code examples I have found so far (e.g. AccountOrderPageLoader) the transactions are normally sorted by createdAt.
Based on the sortings I would expect e-mails to show a wrong payment method if the customer switches the payment method after ordering.
So my question is:
Shouldn't all e-mail templates reference the last entry of the transactions collection to really show the latest state? Or is the sorting for e-mails changed somewhere else?
Thanks for clarification.
I think this is a valid concern but given the standard procedures shouldn't become an issue. This is because when using the StateMachineRegistry to transition from one state to another, the existing state entity is being updated instead of a new one being inserted. So if the transition model is being used as it is intended, there should only be one state per combination of order and payment/delivery method that gets updated, with the former states being persisted as state_machine_history entities to retrace state changes.
Technically however, given that the associations are instances of OneToManyAssociationField, it is obviously possible to persist multiple entities of order_transaction or order_delivery per order when using the corresponding repositories. I think the reason for this relation model being used was to, in the future, potentially allow multiple delivery/payment methods when placing a single order. However this currently isn't implemented which is why it is important to use the proper services to transition between states as explained.
I am trying to customize Optaplanner for my particular use-case. I have been successful so far but now I am struck at the point where I need to have multiple depot and multiple location. Their main use-case seems to be under the assumption that all the vehicle will start from a particular location called depot/warehouse.
In my use-case the conditions are slightly different, The vehicle can start from their own respective locations, meaning there will be multiple depot and multiple customer locations to visit. {MDVRP problem}
for e.g ->
If I have 5 agent and 10 customer location to provide any service, this algorithm assumes
that all these agent will start from same starting location i.e warehouse/depot.
Thus the algorithm will optimize routes based on this assumption and all routes will
start from warehouse
My use case is somewhat like this
If I have 5 agent and 10 customer location to provide any service. Then the algorithm should
start optimizing the route from their own respective location to all the customer location.
So far I have tried custom input to their algorithm. But it doesn't work in an expected manner. Have anyone tried this tool with multiple depot. Any kind of help is appreciated.
The optaplanner-examples implementation supports multi-depot's and it has datasets with multidepots in its data directory. The OptaWeb implementation is based on that model, so the solver should be able to handle it already, but the UI doesn't support this feature yet.
I am designing a system for airport as a part of office project and I am supposed to design a class for handling passengers. I am using WPF MVVM so I have my PassengerInfoViewModel which basically represents a Passenger traveling to Airport. I am confused among using State, Visitor and Decorator patterns.
The requirements:
There are several types of Passengers. Passenger can be a *** with SSN + verified biometrics, SSN + enrolled without verified biometrics, Without SSN + enrolled without verified biometrics, With SSN + enrolled without verified biometrics and other combinations with some other entities.
Any of the above passenger can have one of the following status. NewEnrollment, WaitingForVerification, Verified, Rejected, Deboarded, Cancelled etc. The status of the passenger is updated based on some actions performed by airport staff. But this will be updated not during a single transaction. The updated status will be pulled next time a passenger inputs the Booking Reference number.
A passenger can opt for special assistance that triggers a special workflow. The passenger can check/uncheck special assistance during a single transaction. So, the values keep updating in a single transaction. Once the transaction is over, and if the passenger has opted for Special assistance, this can't be changed again.
What I am planning to do is:
Create a base abstract Passenger class which has basic demographic and other details common across all the passengers. PassengerWithSSN and PassengerWithoutSSN can be a separate class with a VerificatonStatus field Verified, EnrolledPendingVerification etc. This will be fetched when initial transaction begins.
Is this right or should I make separate classes for each type (I am thinking so). Reason being each type triggers a different workflow. As the state does not change during a transaction, I am not going with State pattern.
Also, I should be able to plug different workflows per type in future. Workflows involve calling separate APIs and navigation to different pages.
For NewEnrollment, WaitingForVerification etc, this will be put into a PaxStatus and I am planning to use Visitor pattern to handle the logic for this, keeping it out of the main class. Not sure if this is the right approach.
The SpecialAssistance is something which will change during transaction so I am planning to use State design pattern here. SpecialAssistance state and NormalPassengerState Also there might be an Infant state in case parents want to register Infants for workflows.
There are N*N combinations (e.g. a Non-Verified passenger with Biometrics Enrolled and has SSN travelling with an Infant and needing special assistance) which might mess up needing a lot of rework in future if not designed properly.
Can anyone guide me in the right direction?
I would like to know if we have a planning problem that can be used by many users at a single time. How we can handle this using optaplanner and get optimal solution for all the users?
If every user (or group of users) have their own isolated Solution instance, that's called multi-tenancy. For example: a nurse scheduling web app which services multiple independent hospitals. The planning of 1 hospital (=tenant) does not affect the planning of other hospitals (=other tenants). Basically, every tenant gets their own Solver instance.
If multiple users collaborate on the same Solution instance, then there's only 1 Solver instance which solves that. Either all users have submitted their demands and wishes before Solver.solve() starts, or - in the case of real-time planning - they add/change their demands/wishes from a different thread with Solver.addProblemFactChange() while it's solving. For example: all nurses in a hospital submit their free off day requests before midnight. After midnight, the Solver schedules the hospital, taking those requests into account.
Neither of this is about multi-threaded solving, which is a different topic (but not related to users, so not relevant to your question).
What would be best practice for the following situation. I have an ecommerce store that pulls down inventory levels from a distributor. Should the site, for everytime a user loads a product detail page use the third party API for the most up to date data? Or, should the site using third party APIs and then store that data for a certain amount of time in it's own system and update it periodically?
To me it seems obvious that it should be updated everytime the product detail page is loaded but what about high traffic ecommerce stores? Are completely different solutions used for that case?
In this case I would definitely cache the results from the distributor's site for some period of time, rather than hitting them every time you get a request. However, I would not simply use a blanket 5 minute or 30 minute timeout for all cache entries. Instead, I would use some heuristics. If possible, for instance if your application is written in a language like Python, you could attach a simple script to every product which implements the timeout.
This way, if it is an item that is requested infrequently, or one that has a large amount in stock, you could cache for a longer time.
if product.popularityrating > 8 or product.lastqtyinstock < 20:
cache.expire(productnum)
distributor.checkstock(productnum)
This gives you flexibility that you can call on if you need it. Initially, you can set all the rules to something like:
cache.expireover("3m",productnum)
distributor.checkstock(productnum)
In actual fact, the script would probably not include the checkstock function call because that would be in the main app, but it is included here for context. If python seems too heavyweiaght to include just for this small amount of flexibilty, then have a look at TCL which was specifically designed for this type of job. Both can be embedded easily in C, C++, C# and Java applications.
Actually, there is another solution. Your distributor keeps the product catalog on their servers and gives you access to it via Open Catalog Interface. When a user wants to make an order he gets redirected in-place to the distributor's catalog, chooses items then transfers selection back to your shop.
It is widely used in SRM (Supplier Relationship Management) branch.
It depends on many factors: the traffic to your site, how often the inventory levels change, the business impact of displaing outdated data, how often the supplers allow you to call their API, their API's SLA in terms of availability and performance, and so on.
Once you have these answers, there are of course many possibilities here. For example, for a low-traffic site where getting the inventory right is important, you may want to call the 3rd-party API on every call, but revert to some alternative behavior (such as using cached data) if the API does not respond within a certain timeout.
Sometimes, well-designed APIs will include hints as to the validity period of the data. For example, some REST-over-HTTP APIs support various HTTP Cache control headers that can be used to specify a validity period, or to only retrieve data if it has changed since last request.