imit_model / AnyLogic / UsersManual(AnyLogic)

AnyLogic V User’s Manual

•You can inherit your message class from another base message class. Thus your message class inherits all fields and methods of the base class. In this case access to base member fields is straightforward. The message inheritance is set by specifying the base message class name in the Base class property of your message class. Note that the derived class members will override the class members of the base class.

The choice among these techniques depends on what you want to achieve. If you want to have a reusable message that can contain a message of any type, you use the first technique. If it is vital for your model to have simple access to message parameters, the second solution is preferable.

7.3 Defining custom port classes

You can customize the port behavior by writing your own code in the On send action, On receive action and Additional class code sections of the port properties. However, if the defined port functionality is frequently needed, defining your own port class is preferable. Thus, instead of writing the same code in the properties of all the port instances in your model, you need just to create port class once and specify the created port class name in the Port type properties of the ports in the model. You can create your own port class in code, external file, or a library. Defining port class in an external file or in a library has an advantage of future reuse of your custom ports in other models as well (see Chapter 19, “Libraries and external files” for details).

This section gives the detailed description of AnyLogic port classes and describes how to create your own port classes to customize the default behavior of ports and change the semantics of message passing.

7.3.1Predefined port classes

AnyLogic has two predefined port classes: Port for a port without a queue and PortQueuing for a port with a queue. If you want to customize the default behavior of ports, you need to define your own port class, derived from one of these base classes.

AnyLogic V User’s Manual

Table 11. Port class methods

7.3.1.2 PortQueuing class

The class is derived from the Port class and adds the functionality for message queue management.

The methods of the PortQueuing class are listed in Table 12.

AnyLogic V User’s Manual

Double time

String name

String address

The message contents checking operations are specified in the On receive action property of the port:

if (msg.time + msgLifetime < getTime() || msg.name==null || msg.address==null)

return false;

else {

// process the request

return true;

}

The outdated requests are detected by comparing the message lifetime with the current model time. The messages with the invalid timestamp value as well as the messages with unfilled required fields are discarded.

7.4.2Filtering messages by message type

Sometimes you may need to filter incoming messages by message type – i.e., accept only messages of the certain type and discard other ones. It is commonly used when an object broadcasts messages of different types to a group of recipients and it is necessary to receive messages of one type only in certain ports, while the messages of another type in another ones.

Message type checking is implemented by specifying the type of messages that are accepted by the port in the Message type property of the port. Those messages that cannot be cast to the specified message type are discarded. If Message type is left blank, the predefined Java class Object is assumed – i.e. the port accepts all messages.

Note that message type checking is performed only for messages received at a port, but not for messages sent through a port.

AnyLogic V User’s Manual

Class: Car

a)

Class: Truck

b)

Figure 82. Message filtering by type

7.4.3Sending a message with a delay

According to the time semantics of the message passing, once sent, the message gets to all destination ports immediately. However, it is frequently needed to delay message sending through a port for a specified period of time. In the case of entity flow, delay is typically used to model time spent on processing an entity at active object – e.g., for serving customers in service systems or for producing and processing parts or products in manufacturing models.

The delayed message passing can be implemented in different ways: you can model delay by using dynamic timers (see Chapter 8, “Timers”) or timed transitions in statecharts (see Chapter 9, “Statecharts”). However, using timers is more efficient.

You can implement delayed message sending in the following way: you create a dynamic timer that exists for a specified period of time, modeling message processing delay. When this time elapses, the timer expires and the message is sent via the port.

Therefore, define the sendDelay() method in the Additional class code property of the port. The method takes a message and a delay as parameters and passes them to the created instance of SendTimer timer class that you should define in your active object class.

void sendDelay( Object msg, double delay ) {