Use the mqsicreatebroker command to create an integration node on a Windows system.
>>-mqsicreatebroker--integrationNodeName------------------------> >--+-------------------------+--+-----------------------+-------> '- -i --+-serviceUserId-+-' '- -a --servicePassword-' '-LocalSystem---' >--+------------------------+--+----------------+---------------> '- -q --queueManagerName-' '- -w --workPath-' >--+------------------------------+--+------+--+------+---------> '- --node-conf-yaml --workfile-' '- -t -' '- -m -' >--+-------------------+----------------------------------------> '- -l --userLilPath-' >--+----------------------------------+-------------------------> '- -g --configurationChangeTimeout-' >--+------------------------------------+-----------------------> '- -k --internalConfigurationTimeout-' >--+------------------------+-----------------------------------> '- -P --httpListenerPort-' >--+-------------------------------+----------------------------> '- -v --statisticsMajorInterval-' >--+------------------------------------------+-----------------> '- -y--ldapPrincipal-- -z--ldapCredentials-' >--+------------------------+--+--------------------+-----------> '- -c --icuConverterPath-' '- -x --userExitPath-' >--+---------------------+--+--------------------+--------------> '- -o --operationMode-' '- -s --+-inactive-+-' '-active---' >--+----------------------+--+---------------------+------------> '- -e --sharedWorkPath-' '- -d --+-defined---+-' '-undefined-' >--+-------------------+--+----------------------+--------------> '- -b --cachePolicy-' '- -r --cachePortRange-' >--+-------------+--+-------------------------+-----------------> '- -C --CCSID-' '- -B --brokerDomainGroup-' >--+-------------------------------+--------------------------->< '- -Q --queueManagerDomainGroup-'
For restrictions on the character set that you can use, see Characters allowed in object names.
You can specify the serviceUserId in any valid user name syntax:
username
.\username
username@domain
domain\username
\\server\username
If you use the unqualified form for this user ID (username), the operating system searches for the user ID throughout its domain, starting with the local system. This search might take some time to complete.
The serviceUserId that you specify must be a direct or indirect member of the mqbrkrs local group. The serviceUserId must also be authorized to access the home directory (where IBM App Connect Enterprise has been installed), and the working directory (if specified by the -w parameter).
If you specify that the integration node is to run as a WebSphere MQ trusted application (-t parameter), you must also add the service user ID to the mqm group.
The security requirements for the serviceUserId are described in Security requirements for Windows systems.
If you are using a system and you do not specify -i, then the default is LocalSystem.
If you specify LocalSystem, the servicePassword parameter is not required.
If you specify the -e parameter, LocalSystem should not be used. When specifying the -e parameter, you must use a real userid for the -i option. For Windows, only the -i LocalSystem parameter is available. If you specify the -e parameter for a multi-instance integration node, the system issues an error (BIP8022E: Invalid service userid and password combination supplied).
For compatibility with existing systems, you can specify <password>. However, if you do not specify a password with this parameter when you run the command, you are prompted to enter a password. You must enter the password a second time to verify that you have entered it correctly.
The queue manager specified on the integration node is also required for message flow nodes that
use system queues to store state information about messages, such as the CD and FTE nodes, and for
event-driven processing nodes that are used for aggregation and timeout flows, message collections,
and message sequences. These nodes require a queue manager to be specified on the integration node,
and they also require a set of system queues to be created. You create the queues by running the
script iib_createqueues.bat in the install_dir\server\sample\wmq directory.
Alternatively, you can create the queues by running the WebSphere MQ
define qlocal command. For more information about using the define
qlocal command, see the WebSphere® MQ product
information. For more information
about the IBM App Connect
Enterprise features that require system queues, see mqsicreatebroker command.
If you specify a queue manager that does not exist, you must create it before the flow is deployed.
If the -q parameter is not specified, some features that require access to WebSphere MQ will be unavailable. For more information about using WebSphere MQ with IBM App Connect Enterprise, see Enhanced flexibility in interactions with IBM MQ and Installing IBM MQ.
crtmqm -md \<integration node sharedWorkPath>\mqm\qmdata
-ld \\<integration node sharedWorkPath>\mqm\qmlog queueManagerName
For restrictions on the character set that you can use, see Characters allowed in object names.
If you specify this parameter, a subdirectory with the name of this integration node is created to store its work files; for example: if you specify C:\ACEwork when creating an integration node named MyNode, then the subdirectory created is C:\ACEwork\components\MyNode. (This working directory is a subset of the IBM App Connect Enterprise working directory structure; it contains fewer sub-directories and no common\profiles subdirectory.) If you specify a directory name that does not exist, it is created automatically. You must have permission to create this directory, or the command fails and returns an error.
If you do not specify this parameter, the files are stored in a subdirectory of the IBM App Connect Enterprise working directory, which was set when the product was installed. For example, for an integration node, node_name, the default working directory on Windows is C:\ProgramData\IBM\MQSI\components\node_name.
echo %MQSI_WORKPATH%
When an integration node has been enabled for multi-instance mode using the -e flag, the integration node workPath is divided between data that is specific to this integration node instance, and that which is shared between this integration node and any of its instances created using the mqsiaddbrokerinstance command. Data specific to the multi-instance enabled integration node is stored in the workPath directory on the local server, whereas the shared data is held in a directory on network storage at the location that is specified using the -e flag.
This directory is also used for trace records that are created when tracing is active. These records are written to a subdirectory, log, which you must create before you start the integration node.
Error logs that are written by the integration node when a process ends abnormally are stored in this directory.
The error log is unbounded and continues to grow. Check this directory periodically and clear out old error information.
To change the work path directory after the integration node has been configured, you should delete and then re-create the integration node with the new work path directory.
When the integration node is created, the file is copied to workdir/components/integrationNodeName/node.conf.yaml. If the node-conf-yaml parameter is not provided, the default node.conf.yaml file is copied.
If you specify this parameter, add the serviceUserId (identified by the -i parameter) to the mqm group.
For more details about using WebSphere MQ trusted applications, see the
Intercommunication section of the WebSphere MQ Version 7.5 product
documentation online.
Do not include environment variables in the path; the integration node ignores them.
Create your own directory for storing your .lil or .jar files. Do not save them in the IBM App Connect Enterprise installation directory.
If you specify more than one directory, separate directories by using a semicolon (;).
A message flow cannot respond to a configuration change while it is processing an application message. An integration server returns a negative response to the deployed configuration message if any one of its message flows does not finish processing an application message and apply the configuration change within this timeout.
Specify the value in seconds, in the range 10 - 3600. The default is 300.
For information about how to set the value for this timeout, see Setting configuration timeout values.
The response time of each integration server differs according to system load and the load of its own processes. The value must reflect the longest response time that any integration server takes to respond. If the value is too low, the integration node returns a negative response, and might issue error messages to the local error log.
Specify the value in seconds, in the range 10 - 3600. The default is 60.
For information about how to set the value for this timeout, see Setting configuration timeout values.
The integration node starts this listener when a message flow that includes HTTP nodes or web services support is started; the default is 7080.
Ensure that the port that you specify has not been specified for any other purpose.
Specify the administrative security status for the integration node. If you specify -s active, administration security is enabled. Only user IDs that you authorize are permitted to complete actions on the integration node. Read, write, and execute authority is always granted on the integration node to all user IDs that belong to the security group mqbrkrs. When the integration node has been created, you can add further user ID authorizations.
If you are using queue-based security, the queue SYSTEM.BROKER.AUTH.integration_server_name is created when you create an integration server on an integration node for which administrative security is enabled. Populate the queue with the appropriate user authorization.
If you specify -s inactive, or omit this parameter, integration node administration security is not enabled. All users are able to complete all actions against the integration node and all integration servers.
If integration node administration security is not enabled, web users can access the web user interface as the default user, with unrestricted access to data and integration node resources.
This option is an alternative to starting a multi-instance integration node in standby mode using the mqsistart command.
If you specify -d undefined, the MQ Service is not defined to the queue manager, and the integration node does not start and stop when the queue manager starts and stops. This is the default setting.
mqsicreatebroker INODE -q myQmgr
mqsicreatebroker INODE -i wbrkuid -a wbrkpw -t
mqsicreatebroker INODE -i wbrkuid -a wbrkpw -x /opt/3rdparty/wmbexits
mqsicreatebroker INODE -s active
mqsicreatebroker INODE -o scale