Inform Cell about number of Activities targeting it

[1nf0rmagician]

Is your feature request related to a problem? Please describe.
The following requirements are related to this issue and could be solved by adding this feature

• Showing the user the work backlog on manual cells (e.g. 49 Assembling Activities for Product X are still pending)
• Manual de-/activating resources based on backlogs (e.g. asking additional operators to man a dormant manual cell to work in parallel
• Prompting Instructions to raise a Setup-RTW when no pending Production Activities are present, but Setup Activities are waiting (i.e. Allow to manual start Setups while processes of a different job are still present)
• (Warn about required measures to keep up production, e.g. refilling material)
  This one could also be taken care of in a properly fletched out Material Management module

Describe the solution you'd like
I would like to either include a method in ICell or add an additional interface respected by the process engine with a method to be called with a form of TargetingContext. Following is a first draft of my proposal

public interface ITargetedCell 
{
    void TargetingChanged(TargetingContext context);
}

public class TargetingContext 
{
    public TargetingEvent Change { get; internal set; }

    public Activity Changed { get; internal set; }

    public IEnumerable<Activity> PendingActivities { get; private set; } = []
}

If implemented by the Cell base class, it could provide additional features like

• storing the pending activities in a protected getter only property
• resetting this field on ControllSystemDetached
• provide a getter only property to simplify assessment whether the cell is targeted at all atm

Of course the method call should be decoupled on the process engine, i.e. ignore/log exceptions from the cell implementation and execute the method on a separate thread.

Describe alternatives you've considered
Not really an alternative considered, but it would eliminate one need for accessing the process engine facade (which provides this information) within a resource.

[1nf0rmagician]

@dbeuchler, @Toxantron, @dacky179 would be interested in your opinion on this proposal (especially as the API extension might be relevant for v10.0.0) 🙂

[dacky179]

I actualy do not understand those two properties:
public TargetingEvent Change { get; internal set; } public Activity Changed { get; internal set; }

I miss the other usecase that I want to see amount of unstarted processes.
If you would change public IEnumerable<Activity> PendingActivities { get; private set; } = [] to public IEnumerable<IProcess> PendingProcesses { get; private set; } = [] we could provide ProductionProcesses and UnknownProcesses. This still allows to get all the activities within the process.

I don't think we should add it to Cell because its many data, many events and most time unused.
Could 'detach' be part of the event? Simply send a empty list?

I like our new FacadeToResource-Proposal; At the end its allows more functionality, reuse of existing and known interfaces (Facades) and very less code.

[dbeuchler]

With #865, the ProcessEngineContext was added to the ProcessEngineAttached to provide the Cell a possibility to gather information from the process engine. The class is empty in 10.0 because it defines only the API. Features are implemented in the next feature-releases of MORYX 10.x. This context could contain deeper information of the ProcessEngine like Activities assigned to that resource or pending processes, running processes, ...

I like our new FacadeToResource-Proposal; At the end its allows more functionality, reuse of existing and known interfaces (Facades) and very less code.

I don't know your proposal but that sounds like that you use facades in the Resources which you should not use cause of breaking the architecture and life-cycles. Can you collect missing features from the Resource-point of view? Is there another architectural pattern which you could use? E.g. Register to Resource events from a 3rd module which references your required facades?

[dacky179]

We tried another pattern before but it was... not nice because of the defined direction of the needed interface. (like Fire-Events to do a Method call on a facade and getting a response via method)
In the actual solution we do our best to prevent lifecycle or container problems.
I send a PN for your information.

Can you collect missing features from the Resource-point of view?

• Getting Remaining parts (started and unstarted Processes)
• Get informations about Jobs for precalculations on recipes

Other TargetFacades:

• Change ProductType
• Change Recipe
• Load ProductInstance
• Get Operations for precalculations on recipes.
• Begin or Interrupt operations

[dbeuchler]

like Fire-Events to do a Method call on a facade and getting a response via method

Your current setup uses an event-based callback where Component B raises an event, Component A catches it, and then calls a method on B to provide data. While this keeps A and B loosely coupled, it introduces asynchronous behavior and forces B to manage state. Thats correct and not the best option.

Do you already have thought about: Define an interface that A implements and inject (e.g. in an initialization phase) it into B. B can then (a)synchronously request data without knowing A’s concrete type.

• Getting Remaining parts (started and unstarted Processes): Will be provided in Context introduces in Renamed ControlSystemAttached/Detached and added ProcessEngineContext #865 later
• Get informations about Jobs for precalculations on recipes / Get Operations for precalculations on recipes / Begin or Interrupt operations: Might be a case for the event-based callback / custom context of a custom module?
• Change ProductType/Change Recipe: Why do you want to change a ProductType/Recipe from the Resource?
• Load ProductInstance: Which instance? The instance of the current process?

[dacky179]

Get informations about Jobs for precalculations on recipes / Get Operations for precalculations on recipes / Begin or Interrupt operations: Might be a case for the event-based callback / custom context of a custom module?
Yes we solved it like that but will also be changed to the newer pattern.

Change ProductType/Change Recipe: Why do you want to change a ProductType/Recipe from the Resource?
We have resource UIs those allow to modify values for current production. Saving allows to persist those UI changes for restart into the operation recipe. Another machine asked the User for decision of Invalid data. User should only validate data once. Validation is persisted on the product type.

Load ProductInstance: Which instance? The instance of the current process?
The Product instance of a rework part identified by serial. Serial must be checked before completing the activity with 'loaded' because CS crashes if serial is unknown.