![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
TIBCO ActiveMatrix Adapter for Kenan/BP only provides request-respond service. Typically, an adapter instance can contain one or more request-respond services.This service is often called a Request Reply Server or RPC (Remote Procedural Call) Server. When running as a Request-Response Service, the adapter receives requests from other TIBCO ActiveEnterprise applications and parses them. The output fields are wrapped in a schema and sent back to the caller.
Table 10 Configuration Tab Select the transport type (JMS or TIBCO Rendezvous) to be used by the runtime adapter. This selection determines which options appear in the Transport tab.The transport can be configured to use a trusted store and identity resource for use in SSL (Secure Sockets Layer) configurations. TIBCO Rendezvous sessions and JMS topics have an SSL configuration field which uses a dialog to perform the SSL configuration.To enable and configure SSL, in the Project panel, expand the Advanced folder, then expand the Sessions folder. Select the TIBCO Rendezvous session or JMS topic and click Use SSL?. The SSL configuration options are explained in the online help associated with the session dialog. Click the question mark to display the online help.This tab allows you to specify the Header fields. While configuring the input XML message using an external application like TIBCO ActiveMatrix BusinessWorks, you need to configure only the API specific XML block.
Table 11 Header Fields Tab Specify Header Fields If checked you can specify the header fields in this tab. The runtime adapter will take the values that you have specified in this tab.Note that you can also specify the header values in a request message or in a request response service activity when configuring a TIBCO ActiveMatrix BusinessWorks process. The runtime adapter can extract the header elements that you have specified at process or service level. This is an integer field. The value specified here denotes which customer server is expected to receive the incoming request. This is an Integer field. This field defines the amount of system information you log for an API TS request. The valid values are as follows: This is a string field. This field allows you to specify an identifier for your client application. The value is written to logs. By setting it differently for different clients, you can keep track of transaction volume by client. External TransactionXRef This is a string field. This field allows you to specify an identifier for a transaction. This field is designed to help you identify transactions within the log file. You can use this field to assign a different value for each transaction (group of calls) that you have created. This is a Boolean field. It is used to denote whether the <TraceResults> element should be included in the response to the method call. It helps in tracing each transaction with the Kenan/FX middleware. This is a Boolean field. It lets you specify whether debug information should be written to log files. On a message basis, it overrides the debug settings in the KenanFX.ini file. This is an Integer field. It lets the user specify the maximum number of records for each query to return. On a message basis, it overrides the BlockSize setting in the KenanFX.ini file.<ExternalTransactionXref e-dtype="sting">oracle.xml.parser.v2.XMLElement@1137d4a4</ExternalTransactionXref>As shown in the XML block, the entire XML request is enclosed in <Request></Request> tags. In this, there are two other XML blocks enclosed in <Header></Header> and the <AccountGet></AccountGet> nodes respectively.The Header block contains static information about the nature of the call to the Kenan middleware. The second node is the one containing business entity (for example, Account, Product) and operation (Get, Create) specific information. The node and its contents will change depending on the API call being executed.The adapter supports a feature wherein you can specify the fields under the <Header></Header> tags (also referred to as header fields) separately from the original XML request. By doing so, you have the option to configure only API specific fields as part of the incoming XML message. This can be done through the Header Fields tab.For more information about the parameters in the Header Fields tab, refer to the Header Fields section of the Request Schema chapter in API-TS Guide.Message Transport options can be set for the Request-Response Service depending on the transport type selected in the Configuration tab of the request-response service.The following options appear in the Transport tab if you select Rendezvous as the transport type in the Configuration tab:
Table 12 Transport Tab (Rendezvous) By default, a service uses a message subject that is generated using the Domain and Deployment global variables, the adapter acronym, the adapter instance name, and the service name. If you use this default subject, make sure the values for Domain and Deployment are not empty. You can type a Rendezvous subject name different from the default in this field. See the TIBCO Rendezvous documentation for information about specifying subject names Select the level of service that determines how messages are sent. TIBCO Rendezvous supports the following quality of servicesReliable message delivery ensures that each multicast or broadcast message is received as long as the physical network and packet recipients are working. It also ensures that the loss of a message is detected. This choice can compensate for brief network failures because it can retransmit a message on request if the first attempt failed. This choice is appropriate when message delivery is expected but some loss can be tolerated. Messages are received without explicit confirmation.Certified message delivery offers stronger assurances of message receipt, along with tighter control, greater flexibility, and fine-grained reporting. Guarantees that every certified message reaches its intended recipient in the order sent. The message can be sent across network boundaries, and if a network fails, delivery attempts continue until delivery succeeds or until the message's time limit expires.If certified message delivery is used, data is stored in a ledger file. The size of the ledger depends on several factors, the most important of which is the retention rate of stored data. That means that the ledger grows fastest in response to the cumulative length of undeliverable messages. You must ensure that sufficient disk space is available for the expected size of the ledger.A distributed queue is a group of cooperating transport objects, each in a separate process. To obtain load balancing among servers, the adapter uses distributed queues for one-of-n delivery of messages to a group of servers. Each member of a distributed queue listens for the same subject using the TIBCO Rendezvous Distributed Queue listener objects. Even though many members listen for each inbound message (or task), only one member processes the message. For details on distributed queues, see the TIBCO Rendezvous documentation. The wire format in which data will be sent. If you select TIBCO Rendezvous as the transport type, only the ActiveEnterprise Message wire format is available.ActiveEnterprise Message is an externally-described XML wire format supported by the TIBCO Adapter SDK. Control information for validation is sent in the message. If no control information is included, an exception is returned to the subscriber. TIBCO ActiveEnterprise standard wire format provides class information and packing rules for the TIBCO Adapter SDK set of data types. This format allows TIBCO ActiveEnterprise components to perform extra validation on messages sent or received. XML allows you to retrieve data as XML documents and metadata as XML Schemas (XSD).See the TIBCO Adapter SDK Programmer’s Guide for details about the control information generated and sent with TIBCO ActiveEnterprise messages. When you create a service, TIBCO Designer creates a corresponding session resource in the Advanced > Sessions folder and displays it in this field. If you have explicitly created a custom session of the same type, you can click the Browse button to replace the auto-created session. Endpoint Reference This field is an endpoint reference for the service. It is a disabled field and points to the corresponding endpoint resource in the Advanced > Sessions folder. The endpoint resource is automatically created by TIBCO Designer.The following options appear in the Transport tab if you select JMS as the transport type in the Configuration tab.
Table 13 Transport Tab (JMS) By default, a service uses a dynamic destination that is generated using the Domain and Deployment global variables, the adapter acronym, the adapter instance name, and the service name. If you use this default dynamic destination, make sure the values for Domain and Deployment are not empty. You can override the default dynamic destination by specifying the static destination in this field. The static destination must be defined on the EMS server before it can be used by the runtime adapter.See TIBCO Enterprise Message Service User’s Guide for information on destinations. The wire format in which data will be sent. If you select JMS as the transport type, only THE XML Message wire format is available.The XML Message wire format conforms to specifically constructed and fully compliant XML Schema (XSD) based on the existing definition of the TIBCO ActiveEnterprise schema. Connection Factory Type Point-to-point messaging. A message sent to a queue is consumed by one and only one receiver. Each message has only one receiver though multiple receivers may connect to the queue. The first receiver to access the queue gets the message. The other receivers do not.Publish-subscribe messaging. A message published to a topic is broadcast to one or more subscribers. All messages published to the topic are received by all services that have subscribed to the topic. Delivery mode is the method of delivery for a JMS message. The semantics for these fields are somewhat more complex than the explanation given here. See the TIBCO Enterprise Message Service User’s Guide for more information.Durable indicates that the service is registered with the EMS server. Messages sent to a durable subscription service are held by the EMS server until they are consumed by the service. Even if the service is down, the messages will be received and processed once the service is up.Non Durable indicates that the service is not registered with the EMS server. Messages sent to a non-durable subscription service are not held by the EMS server. If the service stops working, it will not receive the messages that arrived at the EMS server while the service was down.Messages sent with the durable delivery mode are always written to persistent storage, except when they are published to a topic that has no durable subscribers. When a topic has no durable subscribers, there are no subscribers that need messages to be re-sent in the event of a server failure. Therefore, messages do not need to be saved, and performance is improved because disk I/O is not required. When you create a service, TIBCO Designer creates a corresponding session resource in the Advanced > Sessions folder and displays it in this field. If you have explicitly created a custom session of the same type, you can click the Browse button to replace the auto-created session. Endpoint Reference An endpoint reference for the service. This is a disabled field and points to the corresponding endpoint resource in the Advanced > Sessions folder. The endpoint resource is automatically created by TIBCO Designer.
Table 14 Schema Tab
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |