|
|
|
|
|
|
How BEA TOP END Clients Enqueue Messages to /Q
BEA TOP END clients enqueue messages to BEA Tuxedo /Q queues by calling tp_rtq_put(3T). The queue_info parameter is used by the BEA TOP END system to route the request to the TEDG or another RTQ server. The queue_info parameter specifies the RTQ group, RTQ queue name, and RTQ target.
The BEA Tuxedo administrator must create the /Q queue space and create the queue names available within that QSPACE using qmadmin(1). To make the BEA Tuxedo /Q queue space available to the BEA TOP END system, a QSPACE entry for the queue space must be configured in the DM_LOCAL_SERVICES section of the DMCONFIG file and the TE_RTQGROUP, TE_RTQNAME, and TE_TARGET parameters must be specified. The TEDG advertises these parameters when a connection to the BEA TOP END system is established. The status of individual queue space availability in the BEA Tuxedo domain is not tracked while the connection is active.
When a request is received by the TEDG, the queue_info parameter (which defines the RTQ group, queue name, and target) is used to determine the proper queue space. If a target is not specified, none is included in the lookup. The tp_rtq_put service parameter is used to determine the /Q queue name. The TEDG searches the DM_LOCAL_SERVICES section looking for a QNAME entry that matches the product, function, target, and function qualifier from the message. The TEDG enqueues the message using the derived queue space and queue name parameters by calling a function equivalent to tpenqueue(3c). Default values are used as parameters to the tpenqueue options. For example, priority cannot be mapped from an RTQ request, so the default is used. After the message is enqueued, the BEA Tuxedo administrator may use qmadmin to modify attributes of the /Q queue and the messages in it.
The TEDG maps the status returned by the TMQUEUE(5) server and returns it to the BEA TOP END client. On successful enqueue requests, the TEDG assigns a unique RTQ request_id that is returned to the client. The request_id is provided only for tracking the status of requests; it cannot be used in any further administration of the request.
The recipient of the message enqueued to the /Q queue accesses the message in the standard way, depending on whether tpdequeue(3c) is called or TMQFORWARD(5) is used to turn the message into a service request. The buffer type received is determined by the message type sent and the DMCONFIG parameters. Fields on the TPQCTL structure are set to appropriate values, but features such as priority, correlation ID, reply queue, failure queue, and user-return code are not supported by the TEDG; they are either not set or they are set to default values. The appkey and cltid fields are set with the BEA Tuxedo user ID (the DOMAINID of the remote domain) of the client that sent the message.
How the TEDG Works with BEA TOP END Clients
The BEA TOP END client programmer uses the tp_rtq_put(3T) call to enqueue a message to a BEA Tuxedo /Q queue using the TEDG.
As a BEA TOP END client programmer, you need to know the following information:
CARRAY and X_OCTET buffer types have no data marshalling support when transmitted to the TEDG by a BEA TOP END node of a different type. If a BEA Tuxedo service supports FML32 input, the BEA TOP END client uses the BEA Tuxedo FML32 buffer type. FML32 is beneficial because the TEDG and the BEA TOP END system support data marshalling of these buffers when the buffers are transmitted between the TEDG and a BEA TOP END node of a different type. A BEA TOP END service may support one or more of these buffer types.
To make a tp_rtq_put request, you must specify the product, function, MSR target (optional), and function qualifier (optional) associated with the desired BEA Tuxedo queue name in the service parameter.
How the TEDG Maps Client RTQ Requests
A client request may be transactional or non-transactional. The following table shows how BEA TOP END client RTQ flags and parameters are mapped. By mapping these flags and parameters, the TEDG performs a task that is normally done in the BEA TOP END system. The TP_RTQ_HELD and TP_RTQ_NON_TRANSACT_SCHED flags, the transaction key feature, and the tag_length, tag_text, input_format, and attach_info parameters should not be used on requests to the TEDG; they are not supported.
In addition to regular BEA TOP END error status messages, a number of other status messages may be returned to a BEA TOP END client as a result of problems in the TEDG, the BEA Tuxedo system, or the BEA Tuxedo TMQUEUE server. Keep in mind that a single error status message may be used to report any one of many possible causes of the error being reported.
Because the TEDG does not advertise the RTQ queue based upon the actual availability of BEA Tuxedo queue space, a message may be routed to a BEA Tuxedo node where queue space actually is unavailable, resulting in an error status of TP_RTQ_UNAVAIL, while other routing decisions may result in successful requests. If an RTQ queue is to be available on multiple nodes, the design of the BEA Tuxedo application, the BEA TOP END application, and the TEDG must take into account the possibility that this type of failure may occur. A well-designed application, that ensures that there are multiple, restartable copies of the servers, reduces the possibility of such errors occurring.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|