Hello,

The last few years I have performed few K+ Import/Export trainings to developers and have
designed many Kondor+ interfaces
The goal of this post is to explain how to build a java KIS client in RdV native. You could find
attached a fully functional Java RdV KIS Client.
At first i will introduce the K+ Import.
As you can guess, the knowledge of Tibco RdV is mandatory. So in the second part of this tutorial I
will quickly present Tibco Rdv (publish/subscribe mode only).
In the third part I explain the KIS / KIS Client communication and KIS Import message format.
Finally in the last chapter I comment the Java KIS Client source code which is attached.
Most of the subjects discussed here are detailed in Kondor+Import/Export guide. Please always
refer to this guide.
Introduction to Kondor+ Import
In Kondor+ you can import data from an external source to Kondor+ databases (kplus and Kustom).
KIS is the Kondor+ Import Server which is responsible of checking the coherency of import message
and inserting data in K+ databases. To achieve this a Client / Server communication is established.
Therefore you must implement a KIS client.
Here we will only discuss java RdV native KIS clients: KIS client using the java Tibrv API and using
the RdV native message structure.
Communication mode
There are 2 communication modes between KIS and its client:
- Synchronous mode, KIS client is waiting for acknowledgement of previous message before
threating a new import message
- Asynchronous mode, no wait for acknowledgement
Validation Type
The KIS client validation type is a parameter which allows you to define how the K+ deals are
inserted into Kondor+ databases and what to do when an import error occurs.
There are 3 validation type (ComunicationManager --> Import Client)
- Manual: deals need to be manually validated by K+ user
- Semi-auto: deals are inserted, manually if an error occurs
- Auto: deals are inserted, rejected if an error occurs

Tibco RdV
You can find many tutorials on that subject on the web. Here i will take few shortcuts to go quickly
on interesting parts (amongs others i will not talk about certified messaging).
RdV is a message bus allowing communication between different applications through the usage of
RdV APIs. RdV uses a publish / subscribe mode. An application publishes messages and all subcriber
applications can listen to them (RdV is multicast).
We often say that RdV is connectionless which is not totally true.
Daemons intercommunications protocol is UDP but applications must be connected to RdV daemons
via TCP.
In the attached schema rdv.jpg, an application A communicates with an application B through RdV
daemon DA and DB.

To configure RdV communication between application A and application B, we must set the
following parameters:
- Daemon TCP connection parameters between A and DA
- Daemon TCP connection parameters between B and DB
- Multicast network details for inter daemon communication from DA
- Multicast network details for inter daemon communication from DB
- UPD port (service) for inter daemon communication DA and DB
We have then 2 sets of parameters: network, service, daemon.
As described above, network and service are used for rdv daemon communication and daemon
parameter is used for the connection between application and rdv daemon.
Once we have set these 2 sets of parameters, we have open a "channel" between A and B.
To allow applications to exchange different kind of information in this channel, there is an
additional parameter the "Subject" which is used by rdv to segregate messages.
You must understand that the server/client communication is not set in this middleware layer. KIS /
KIS client connection is done on the upper application layer (i.e. implemented in applications using
Tibrv API). We will discuss this communication in the next chapter.
KIS / KIS Client communication
As explained just above, KIS communication is implemented on top of Middleware layer.
There are mainly 3 stages for this communication with the KIS:
Initiation of the connection with KIS
Connection persitency
Send of data message from KIS client to KIS (deal / static data import)
In the attached schema kis_communication.jpg you can see these different phasis.
Let us now describe in details the different messages.
Note about RdV Subjects
The connection request message is sent to KIS on a generic subject. But after that, all messages
from KIS to KIS client are sent on the KIS Client specific subject. And all message from KIS Client to
KIS are sent on KIS specific subject. These 2 subjects are generated by Tibrv API and they are only
used for the communication between KIS and this specific client.
We will call these 2 subjects: KIS_Inbox and KISClient_Inbox.
Connection initiation
Message 1 - KIS Client sends a connection request message to KIS.
The connection subject is build like that: OKAPI.INBOX_REQUEST.<kis_port>.<kis_hostname>
We must also set some TibrvMsgField (list non exhaustive):
- Type: 1 to indicate to KIS it is a connection request message
- Inbox: KISClient_Inbox. It indicates to KIS that from now all messages from KIS to KIS client must
be send to KISClient_Inbox.
- Client name: the KIS Client name as defined in ComManager
- Synchronous mode: 1 or 0
- Messages mode: indicates the message format (KplusFeed text or KplusFeed XML)
Message 2 - KIS send a connection acknowledgment

As explain before, this message is sent on KISClient_Inbox subject.

TibrvMsgField:
- Type: 1
- Inbox: KIS_Inbox. It indicates to KIS Client that from now all messages from KIS Client to KIS must
be send to KIS_Inbox.
Connection persistency
Ping from client to KIS are used to maintain the connection. If KIS does not receive a ping message
after a specific delay, it disconnects the KIS Client. This timeout parameter can be modified in
kis.params.
Message 3 - KIS Client sends a ping request to KIS
TibrvMsgField:
- Type: 3
Message 4 - KIS replies with a ping acknoledgement
TibrvMsgField:
- Type: 3
Sending data from KIS Client to KIS
Messages to import deals / static data into Kondor+
Message 5 - KIS Client sends a data message to KIS (request for deal import for instance)
TibrvMsgField:
- Type: 2
- Key: Kondor+ deal type (BondsDeals for instance)
- XmlBuffer: the KplusFeed message
- XmlBufferLen: size of KplusFeed message
Message 6 - KIS replies with an acknoledgement
- Type: 2
- XmlBuffer: the import status in KplusFeed format. We can extract here the deal Id newly created.
Remarks about timeout and disconnection
Timeout and reconnection management must be implemented on your KIS Client using TibrvTimer.
In this tutorial I do not explain how to deal with these particular states. Most of the time it is also
project specific.
KIS Import Message Formats
When importing a message into Kondor+ via KIS, there are only 2 import formats KplusFeed Text and
KplusFeed XML. These formats are very similar.
For export there is an additional real XML third format.
KplusFeed Text
You have samples of this format in $KPLUSHOME3/entities/$ENTITY_NAME/Import/samples/
KplusFeed XML
This is not a real XML format: line order is taken into account and end of lines are mandatory.
You cannot parse it (XSD, DTD) or transform it (XSLT).
An example of KplusFeed XML is attached to this post (iamdeals.kml).

Java KIS Client implementation

Pre-requisite
- Tibco software installed where the KIS client code is launched (you should launch tibrvlisten

command)
- Create KIS Client in CommunicationManager: "TEST_IMPORT"
- Put KIS is RDV mode by modifying kis.params "COMM_MODE RENDEZVOUS_MODE"
- Add tibrvj.jar to your classpath (C:\TIBCO\TIBR\lib\tibrvj.jar)
- Copy the sample iamdeals message and change its location in java code main method
Run traces sample
Tibco Rdv Transport created
Listening on _INBOX.C0A8A36E.17905035E45B4C86CC0.1
Sending KIS connection request...
Receiving KIS connection reply...
Receiving KIS data ack...
{ Type=2 Inbox="_INBOX.C0A8A36E.5DD5035E462CC0A638.1" Key="IamDeals" Data Type=6
XMLBufferLen=139 XMLBuffer="<KPLUSFEED>
<Kondor+TableId type="U">0</Kondor+TableId>
<Connection_Acknowledgement type="U">kis</Connection_Acknowledgement>
</KPLUSFEED>
"}
Sending KIS ping request...
Sending KIS data message for IamDeals...
Receiving KIS ping ack...
Receiving KIS data ack...
{ Type=2 Inbox="_INBOX.C0A8A36E.5DD5035E462CC0A638.1" Key="IamDeals" Data Type=6
XMLBufferLen=71 XMLBuffer="<KPLUSFEED>
<Kondor+TableId type="U">490</Kondor+TableId>
</KPLUSFEED>
"}
This ends this short tutorial, do not hesitate to tell me if i made a mistake or omitted an important
thing about K+ import.
I also take the chance to present my company 2LA Software, where we have built few modules
around Kondor+. We also directly propose our K+ expertise to Kondor+ clients.
Do not hesitate to have a look on our website http://www.2la-software.com
Our main products are:
Kondor+ monitoring software (MoniK) which intends to improve the Kondor+ application
supervision and reduce incident impact.
Kondor+ Impact Analyser tool which provides an exhaustive impact analysis on your custom code
when migrating Kondor+.
The Kustom Impact Analyser is used by Misys Professional Services in the entire EMEA region.