Common Configurations

This section illustrates the configurations that are common across most of the adapters. However, if there are any additional component-specific details that are not described here, such details can be found in the respective component help file.

Custom configuration can be performed in the Configuration Property Sheet (CPS) as well as the Properties panel - CPS having Component-specific configuration and Properties having Component Instance configuration.

For common configuration details of Configuration Property Sheet (CPS), refer to the Common Configurations section in the Microservices documentation.

Properties Panel

To view/edit properties, use any one of the two options below in the Orchestrator:

• Right-click the component present in the Fiorano Orchestrator and click Properties.
• Open from Window > Show View > Other > General > Properties

Properties section has subsections where Component Instance values can be edited based on the requirement, such as General, Deployment, Execution, Log Manager, Log Module Instances, and Runtime Arguments.

Component Instance Properties

Component instance properties appear in the Properties pane when a component present in the Fiorano Orchestrator is selected. These properties and the attributes present under it are explained in the sections below.

General

This group contains general properties that identify the component instance or affect the appearance of the component instance.

Name

Name of the component instance in the application. This name should be unique in an application.

Guid

Guid (Global Unique Identifier) is a unique name used as an identifier to represent a service/component. This is generally the name of the component itself.

Version

When there are multiple versions of a component with the same GUID, the Version property determines the component that this instance represents.

Example: Web Service Consumer has two versions of components, version 4.0 and version 5.0. Version 4.0 uses axis API and version 5.0 uses axis2 API.

It is recommended that the configuration of the component is compatible across versions when developing custom components.

Short Description

A one line description for the component instance. This description is shown as a tooltip for the component. By default, the value defined for short-description element in the component's Service Descriptor is shown here. If there is no value defined for this property, the default value is shown in tooltip.

Example: For an SMTP component that is configured to send emails using a Fiorano email account, the short description can be amended to give a more appropriate description.

Long Description

A detailed description about the component instance. By default, the value defined for long-description element in the component's Service Descriptor is shown here.

Use Separate Process CPS

Select this check box to use external Configuration Property Sheet (CPS) on a separate JVM instead of the interface available in eStudio. When you open the CPS from the Fiorano Orchestrator after selecting this option, the external CPS opens up. This option can be used when loading the default eStudio CPS is complex and takes up too much memory.

Deployment

It contains the deployment information of the component, which affect the way components are deployed in Fiorano environment. The Peer Server node on which the component has to be launched, and the  can be configured here. 

Nodes

A delimited list of Peer Servers from Fiorano network on which this component instance is launched. The component is launched on the first Peer Server in the list that is available in Fiorano network. If the Peer Server on which the component instance is running shuts down, the component instance fails over to the next available Peer Server.

Click the button against Nodes option to launch Select Nodes editor to configure the Peer Servers.

The peer server present in the Fiorano network appears under Selected Nodes section in the Select Nodes editor. This can be moved to Available Nodes section and used accordingly as mentioned below:

• To add a Peer Server - Select the server you need to add from the Selected Nodes section and click the 

  

  button. The selected server gets added to Available Nodes section. 
• To remove a Peer Server - Select the Server you need to remove from the Available Nodes section and click the 

  

  button. The selected server gets added back to Selected Nodes section, which means this server will not be available for the Service Instance anymore.

• To add/remove multiple servers - Use

  

  and

  

   to move all the Selected Nodes to Available Nodes and all the Available Nodes to Selected Nodes respectively.
  

  If multiple nodes are selected, all the selected nodes appear under Nodes field in the Deployment tab as comma-separated values.

• To change the order of the Peer Servers - Order of priority can be changed using the Up button and the Down button in case of multiple servers.

Fail Over

• If the component instance persists data on the Peer Server on which it is running, then the data is lost when the component instance fails over to a different Peer Server.
• The failover process is equivalent to manually stopping the component instance, changing the Peer Server on which the component instance should be launched and restarting the component.
• Messages that are received by the component instance during the failover are lost.
• This is not the same as failover when Peer Server is configured in HA mode.

Based on the selected Peer Server, the component color changes to give a visual clue as to which Peer the component is configured to launch. By default, when a Peer Server is added to an Enterprise Server, a unique color is chosen. In the below figure, the Feeder and Display components are configured to launch on different servers.

• Changing the Node name at runtime for Worklist and Aggregator services is not supported. Unlike other components, Worklist and Aggregator components have state information written to the local disk. Moving the Worklist (or Aggregator) from one peer server to another results in state data loss. In the case of Worklist, not only the data loss, the external application, that is, Worklist web application will not show work items saved in the Worklist after the node change.
• To achieve high availability for Stateful components, configure the back-end data store in clustered/HA relational database, like Oracle, DB2, and so on. Or deploy the components on a Peer Server that is running in Shared HA mode.

Cache Component

During the development process, some components might have external resources added. Also, for custom-built components, the source files might be updated from time to time. To reflect the changes for such components across the peers at runtime, enable this property to force the resources of the component to be re-fetched each time a Connectivity and Resource Check is done.

• yes
  Resources required for execution by the component instance are fetched from the Enterprise Server and cached on the Peer Server (if not already done) when the CRC (Check Resources & Connectivity) operation is performed in the Event Process.
  A resource can be marked as required for execution in the Service Descriptor.
  If the resources are not changed in the Enterprise Server, then they need not be fetched every time the application is launched, thereby reducing the time taken to perform a CRC operation for the application.

• no
  The resources required for execution by the component instance are fetched from the Enterprise Server to the Peer Server every time the CRC operation is performed.

  

  If there are changes done to the component resources, this property should be set to no before performing the CRC operation and can be reset to yes later.

Execution

This group contains properties that affect launch behavior of the component.

Execution Type

This property specifies how the component instance is launched. There are four possible values.

• Separate Process: The component instance is launched in a separate JVM. It is automatically launched when the application is launched. When this option is selected properties Debug Mode and JVM_PARAMS are visible.

• In Memory: The component instance is launched in the JVM of the Peer Server. It is automatically launched when the application is launched. When this option is selected properties Debug Mode and JVM_PARAMS are not visible.
  
  

• Group Process: This launch mode enables multiple microservices to run in a Single JVM sharing the same resources. This launch mode overcomes certain limitations faced by the two modes mentioned above - the Separate launch mode having a restriction to use a limited number of microservices in a peer and the In Memory launch mode affecting the peer server performance when microservices face memory/thread leak.

  

  To know more about the 3 launch modes above, refer to the Configuring Execution Type section.

• Manual: The component instance is not launched when the application is launched. It has to be launched manually from the command line.

  

  To know more about the Manual launch mode and for further details on using scriptgen, refer to the Manual Deployment section.

• None: If selected, the component instance is never launched. When this option is selected properties Debug Mode is not visible and the value for property JVM_PARAMS is ignored.

The boundary of the component icon is changed to provide a visual clue for the launch type selected. The below figure shows the change in the boundary of a component instance for each launch type.

Prefer First Node

To prefer the first launch on the highest available node, that is, whether or not the launch of this service instance is preferred on the highest level.

Kill Primary

To kill Primary Service Instance when Secondary launches.

If a service is bound to a Peer Server and when another service with the same name tries to bind with the same Peer Server, then the 2 options available are:

• Yes
  Primary service will be killed and secondary service will take its place.
• No
  Secondary server kills itself.

Debug Mode

• yes
  The component instance is launched in debug mode. A debugger from any IDE can be attached to the component instance to debug the component instance step by step at runtime. When this value is selected, the property Debug Port is visible.

• no
  The component instance is not launched in debug mode and a debugger cannot be attached. When this value is selected, the property Debug Port is visible.
  This property is only used when the property Launch Type is set to Separate Process. To debug the component instance launched in the memory of Peer Server JVM, debug parameters have to be in the configuration file – %FIORANO_HOME%\esb\fps\bin\fps.conf – of the Peer Server.

Debug Port

The port on which the component waits for instructions from the debugger.
When property Debug Mode is set to yes, then the property Debug Port is set to 5000. It is equivalent to launching the component with the following command line arguments:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5000

The component instance can be alternatively launched in debug mode by specifying the required command line arguments in the property JVM_PARAMS.

Buffer Limit

Maximum buffer size (bytes) that to be stored per port. The Peer Server starts generating alerts when the number of bytes comes close to this limit.

Configuration

The serialized configuration of the component instance. Any changes made to this are reflected when the component instance is launched or the CPS of the component instance is opened.

Connection Factory Properties

Connection Factory settings modified from peer connections will be lost when the component is stopped or event process is stopped. In order to make it persistent, add connection factories which thereby gets added in EventProcess.xml file for the specified Service Instance.

Click Add button and select the property from the Name drop-down and provide appropriate value to save a particular Connection Factory property.

Enterprise server will take care of creating Service Handles along with Connection Factory Settings and passing these properties to the respective peers upon restart.

Log Manager

Contains logging information as described below.

• Type: Type of log handler, for example, File, Console.
• Class Name: Class name of the specific Log Type.
• Directory: Name of the directory where Log files are stored.
• File Size: The maximum file size after which a new Log file has to be created.
• # of files: Maximum number of Log files to be maintained.
• Include Time Stamp: To include Time-stamp in Log Message
• Time Stamp Format: To set the format in which time stamp needs to appear in the Logs. Default value is "MM/dd/yyyy HH:mm:ss"

Log Module Instances

This group contains different loggers that are used and their log level configuration.
All the loggers that are used by the component instance are shown as properties in this section. The level at which logging should be performed for each logger is defined below.

There are nine logging levels (Values) available in the drop-down list – Off, Severe, Warning, Config, Info, Fine, Finer, Finest, and All.

By default, the log level is set to SEVERE. This can be changed to the desired level. For example, the log level can be set to CONFIG when working on the Development environment.

When the component is launched, all the component log module instance names are modified to include Event Process name, Service Instance name and Service GUID to maintain uniqueness.

For example, if the log module instance name of a component is "com.fiorano.services.display.DisplayService", then after the component is launched, some extra information is included and is changed to "EVENT_PROCESS1.COM.FIORANO.SERVICES.DISPLAY.DISPLAY1.DISPLAYSERVICE" and the logger is created with the changed name. In the above example, the log module instance name has the service GUID name "Display".

If the original name doesn't have Service GUID name, then Application Name, Sevice GUID, and Service Instance name is pre-pended to the log module name. For example, if the log module instance name is "org.apache.ws.security.processor.SignatureProcessor", then after the component is launched, it is changed to "COMMUNICATIONS_IN.WSSECURITY.WSSECURITY1.ORG.APACHE.WS.SECURITY.PROCESSOR.SIGNATUREPROCESSOR" and the logger is created.

Changing the log module instance names at component startup is required to maintain the uniqueness of components logs especially when multiple instances of a component are running in the same JVM.

However, this does make logging from 3rd party jars difficult to manage when working with custom components. To avoid this, the property Append service Info is useful for controlling log levels of loggers used by third-party libraries, since the handlers for such loggers will be created without appending service info to the logger names used by them.

• This property should not be enabled for default loggers used by Fiorano pre-built components and loggers generated by default in custom components.
• If all the loggers need to be set with the same value, for example, "INFO", select this log level value for the property All Levels.

For information about log levels and the effect they have on logs generated, please refer to http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Level.html.

Runtime Arguments

Contains the information about the runtime arguments for the service. It has a single property JVM_PARAMS which contains all command line parameters that are passed to launch the component.

This property is used only when the Launch Type of the component instance is set to 'Separate Process'. Any system properties can be set using this property.

Example

To support regional language-specific characters during HTTP transfer, character set encoding of the regional language has to be specified using the system property file.encoding. The system property can be provided as -Dfile.encoding=<required_encoding> for this property. If there are some other properties already defined, then the value to add should be appended to the existing value separated by a space.

JVM_PARAMS section contains the JVM parameters that are used while launching the component. Whenever a change is made in JVM PARAMS section, the Update all Service Instances dialog box appears asking whether the change has to be updated for all the service instances in all Event Process having the same JVM PARAMS value.

If No option is selected, then it updates to the current service instance. If Yes option is selected, a dialog listing the service instances with same JVM PARAMS value appears and the required service instances can be selected for an update.

Configuring Connection Timeout

In microservices such as FTPGet, FTPPut, and FileReader, an input/output operation may get hung for indefinite time waiting for a request to return due to various reasons such as network fluctuations of the mounted directory. To avoid such waiting time, it is recommended to configure Connection Timeout in the runtime arguments. This is done by adding a property "-DCONNECTION_TIMEOUT" with the value (in milliseconds) as per requirement in Runtime Arguments in the Properties pane.

To configure Connection Timeout, 

1. Click the microservice present on the orchestrator editor.

2. In the Properties pane, click the Runtime Arguments tab and append the following values in the JVM_PARAMS text area:

   Append to the JVM_PARAMS values

   ACTIONSCRIPT3

   -DCONNECTION_TIMEOUT=3000

   

   
   Figure 12: Configuring the runtime arguments by editing the JVM_PARAMS value to manage memory
   
   

3. Press Enter to save the configuration and click the option "No" or "Yes" to update this configuration only to the current service instance alone or for all event process respectively.

After configuring Connection Timeout as above, the maximum time that the component waits for execution of each file will be 3000 milliseconds (3 seconds). If a CONNECTION_ERROR is thrown while the request is expecting to read N number of files, then the execution of all the remaining files for that request will be discarded. Once the CONNECTION_ERROR has occurred, the next request from the input port is processed in sequential order.

If an error occurs while configuring -DCONNECTION_TIMEOUT in runtime arguments, then the microservice takes the default value 180000 milliseconds (3 minutes). For example, if -DCONNECTION_TIMEOUT is set to an empty value or if it throws NumberFormatException due to a typing error like "_DCONNECTION_TIMEOUT=30)0", then this default value is taken.

When configuring the timeout, the component takes the value from different locations in different Launch Modes as below:

1. Separate Process: Properties -> Runtime Arguments -> JVM_PARAMS
2. In-memory: When the microservice is launched in the In-memory launch mode, the property 'CONNECTION_TIMEOUT' (in %FIORANO_HOME%\esb\server\bin\server.conf, if FPS is launched using server.bat/server.sh or %FIORANO_HOME%\esb\fps\bin\fps.conf, if FPS is launched using fps.bat/fps.sh) should be set to some value as mentioned below:
   
   

   

   
   Figure 13: Mentioning Connection Timeout value in the Server configuration file

Port Properties

Component port properties can be configured by choosing the port and configuring the appropriate property in the Properties panel.

Input Port Properties

Input port properties appear in the Properties pane when the input port of a component instance is selected.

Input port properties for an SMTP component are explained below.

General

Name

Name of the Input Port

Desc

Description to brief the functionality of the port.

Configuration

The serialized configuration of the component instance. Any changes made to this are reflected when the component instance is launched or the CPS of the component instance is opened

Workflow

Specifies the role of this port in the workflow. The options available are:

• No WorkFlow
• Workflow Item
• Workflow End

Workflow Item and Workflow End can be selected accordingly to specify the role of the port. When either of these ports is selected, the next attribute 'Workflow Data Type' gets highlighted for further customization.

Workflow Data Type

This attribute is used to specify the part of the document that needs to be tracked, which helps Document Tracking. The attributes that can be tracked are:

• Message Header
• Message Body
• Attachments
• Application Context

• This option gets enabled only when either of the options—Workflow Item or Workflow End are specified in Workflow)
• Message Body will be tracked by default.

Please refer to Document Tracking for more information.

Enable Callout

Specifies whether the Callout config is enabled or not.

Callout Parameters

Specifies DB callout parameter types for the workflow.

JMS Destination

This group contains properties related to destinations created for the ports of the component.

Configuration

The serialized configuration of the component instance. Any changes made to this are reflected when the component instance is launched or the CPS of the component instance is opened.

Destination Type

Specifies whether the destination for the port is 'Queue' or 'Topic'. Visual representation of port is changed based on the type of the destination as shown below. Square shape indicates a Queue and a circle indicates a Topic.

• When this property is set to Queue, the property Durable Subscription is not visible.
• When this property is set to Topic, the property Durable Subscription is visible.

Custom Destination

Destinations for each port in the application are created automatically and associated with a port when the application is launched. The destination name for destination created and associated to a port is constructed using the following function:

<Event Process GUID>_<Component instance name>_<Port name>

Example: If an Event Process whose GUID is SAMPLE_APP contains an SMTP component instance with name MAIL_SENDER. The destination created for the input port is SAMPLE_APP_MAIL_SENDER_IN_PORT.

However, if the destination to be used has to be explicitly defined, then this property should be set to yes.

• When this property is set to yes, the property Destination Name is visible.
• When this property is set to no, the property Destination Name is not visible.

Destination Name

The name of topic or queue that has to be associated with the port. The destination is automatically created if it is not present.

Destination Encryption

Destination Encryption allows storage of sensitive data from different publishers in a secure way. Encryption implies the transformation of plain text into cipher text by using "key" A key is also used to decrypt the cipher text into plain text.

Destination Encryption Characteristics
In Destination Encryption, all messages sent to a particular destination (topic or queue) are encrypted, thus providing a secure channel of delivery. A component does not have to encrypt the message explicitly like in Message Encryption. A destination is marked as encrypted at the time of its creation. All messages published on this destination are encrypted before storing those in the database and delivered decrypted to subscribing applications. A client application, therefore, does not have to explicitly decrypt a received message.

Base Implementation
Fiorano 9.5.0 and higher versions support Destination Encryption.

DES (Data Encryption Standards) is used as the default encryption algorithm. In addition to that Fiorano 11 supports Base64, TripleDES, AES256, AES128, AES192, RC2-40, RC2-64, and RC2-128.

The Destination Encryption function uses the library cryptix.jar provided by Cryptix for generating keys as well as for encryption. This file comes bundled with the Fiorano 11 installation. It can be found in the FIORANO_HOME/extlib/cryptix directory of the Fiorano 11 installation.

Destination Encryption involves only encrypting the payload of the message and not its JMS headers and properties.

Encrypted Destination Creation
Input/Output port properties appear in the Properties panel when an input port of a component instance is selected.

Is Encrypted

• Yes
  Encrypted JMS destination will be created.
• No
  Non Encrypted JMS destination will be created.

Encryption Algorithm

The supported algorithms are DES, Base64, TripleDES, AES256, AES128, AES192, RC2-40, RC2-64, and RC2-128.

Encryption Key

Specify key which is used to encrypt the incoming data. Specify 64 digit key for AES256, 48 digit key for AES192, 32 digit key for AES128, 16 digit key for DES, 48 digit key for TripleDES, 10 digit key for RC2_40, 16 digit key for RC2_64 and 32 digit key for RC2_128.

Allow Padding to Key

Choose yes to allow padding to the key to match the value required for the mentioned algorithm.

Messaging

This group contains properties related to JMS messaging concepts. In general, pre-built components provided by Fiorano use a single connection and share the same session for reading messages in the input port and sending messages to the output port.

Configuration

The serialized configuration of the component instance. Any changes made to this are reflected when the component instance is launched or the CPS of the component instance is opened.

Transacted

Specifies whether the JMS session is transacted or not.

• yes - JMS session is created as a transacted session. Multiple input messages can be grouped into a single transaction. Messages are not sent on the output port of the component until the transaction is complete. They are held in-memory of the component. When this value is selected, property Transaction Size is visible.
• no - JMS session is created as a non-transacted session. Messages are sent on the output port of the component immediately. When this value is selected, property Transaction Size is visible.

When the output of component is very large, it is not advised to set this property value to 'yes'.

A transaction is based on the number of input messages processed and not based on the number of output messages sent. In cases, where a component sends a large number of output messages for each input request, it is not advised to set this property value to yes even if the value for property Transaction Size is set to 1.

Example: A File Reader component reading a large binary file or a DB component that returns a result set containing a large number of rows.

Transaction Size

Number of input messages that should be processed before committing the transaction.

Number of Sessions

Number of sessions that are created by the component instance to process messages received on the input port. Messages are processed in a separate session by each thread. This property is used to increase the number of threads that can process the requests and thereby increase the throughput. However, the number of threads that can at a time is restricted by Max Pool Size property in Connection Pooling Configuration panel.

Acknowledgement Mode

Specifies the acknowledgment mode that is used to acknowledge messages. Messages are not deleted from destinations until they are acknowledged. When the component fails over because of the HA failover of Peer Server, all the messages that are not acknowledged are redelivered. The number of duplicate messages in case of failover can be controlled using this property.

DUPS OK

Messages are acknowledged after configured number of messages are successfully processed and output messages are sent by the component instance. The number of messages after which the messages are acknowledged can be configured at the following node in FMQ profile – Fiorano > mq > pubsub > TopicSubSystem > DupsOkBatchSize. Number of duplicate messages is utmost the DupsOkBatchSize for each session on each input port of the component instance.

AUTO ACKNOWLEDGE

Messages are acknowledged after a message is successfully processed and the output message is sent by the component instance. Hence, number of duplicate messages is utmost 1 for each session on each input port of the component instance.

CLIENT ACKNOWLEDGE

This property is ignored if the property Transacted is set to yes. When the property Transacted is set to yes, messages are acknowledged when the transaction is committed. Hence, number of duplicate messages is utmost the number denoted by property Transaction Size for each session on each input port of the component instance.

Durable Subscription

Specifies whether a durable subscriber is created on the destination represented by the input port or not. This property is visible only when the value for the property Destination Type is set to Topic.

• yes - A durable subscription is created to the topic represented by the input port. Messages sent to the topic are not lost when the component fails over because of the HA failover of Peer Server. If selected, then the property Subscription Name is visible.
• no - A durable subscription is created to the topic represented by the input port. Messages sent to the topic may be lost when the component fails over because of the HA failover of Peer Server.

If the Destination Type is 'Queue', then messages are not lost when the component fails over because of the HA failover of Peer Server.

Following components do not create durable subscriptions and hence have to use only queues as input ports – WSStub and HTTPStub.

Subscription Name

Subscription name that should be used for creating a durable subscriber. This should be a unique name for the Peer Server on which the component instance is running.
Client ID

Unique ID for the JMS connection created by this port. This property is not used by pre-built components provided by Fiorano as there is only one connection created for each component instance.

Message Selector

Specifies a condition (JMS Message Selector) to select only a particular set of messages.

Application Context

Helps to manage the Application Context that is configured for the application / Event Process.

Action

Application Context can be used effectively by choosing the below options appropriately.

No Action

No Action is the default mode which is similar to not defining any particular action on the Application Context.

Store Application Context

Stores the Application Context to use it on a future instance.

Restore Application Context

Restores the Application Context which was stored previously.

Set Default Application Context

Uses the default Application Context instead of the one created separately

Message Filters

Messages can be filtered by providing a specific name and value to it under the Name and Value columns respectively.

Input port configured with specific values accepts only those messages that match the criteria specified in the Message Filter. If the message content does not match the criteria, the message is discarded.

For an Input Port  with a Message Filter, make sure that you set the same values in the Output port if the Input Port needs to accept the message.

Output Port Properties

Output port properties appear in the Properties pane when an output of a component instance is selected.

Output port properties for an SMTP component are shown below.

General

General Properties of Output Port  have the same functions as that of the General Properties of Input Port.

JMS Destination

This group contains properties related to destinations created for the ports of the component. For more information, refer to JMS Destination section under Input Port Properties.

Messaging

Time to Live

Specifies the time in milliseconds for which the message is available from the system after it is sent from the producer. The message is discarded on the expiration of this time. 0 (zero) milliseconds indicate infinite lifetime.

Example: Consider an application contains four component instances. Value for this property is set to 30000 milliseconds on the output port of the first component instance. This means, once the message is sent on the output port of first component instance, the message should be consumed by the fourth component instance in 30 seconds. If it is not consumed in 30 seconds, then the message will be lost and will never reach the fourth component.

Message Priority

The priority of the message sent; can be any integer value from 0 (zero - lowest) to 9 (nine - highest). The default priority is 4.

Persistent Messages

Specifies whether the producer on this port sends persistent messages or not. If this property is set to yes, all messages are persisted to message store. If this property is set to no, the messages are not persisted and there may be message loss noticed during the HA failover of the Peer Server.

Preventing message loss

To avoid message loss in Fiorano Event Processes, change the following properties -

• On each output port, set the value of property Persistent to yes.
• On each route, set the value of property Durable to yes.
• On each input port that is a topic, set the value of property Durable Subscription to yes.
• Whenever a JMS* component is used, make sure all messages sent are persistent and all subscriptions to topics are durable. These properties can be set in CPS of JMS components.

Components with implicitly defined JMS messaging properties

Some of the less used components in Fiorano have Acknowledgement Mode, Transaction Type, and Transaction Size implicitly defined and will not pick the values from the input port.

Application Context

In the Output Port Application Context, you have an option to choose the Component Instance from the Configuration drop-down if it was saved after creating the Application Context. Rest of the options are the same as in Input Port properties.

Message Filters

Refer to the content in Message Filters under Input Port properties.