Writing a T-Lib client using either the old (unsupported) T-library or newer Platform SDK is a fairly easy task and the complexity of the underlying wire protocol is not an issue.
However, what if you need to write a T-Lib server component?
You may ask why we might need to do this.
As part of this project we need to integrate Verint Impact 360 / Blue Pumpkin workforce management with Genesys to replace the existing integration via CMS. Out of the box Verint provide real-time adherence integration via their CSTI adapter for Genesys. However, the client already has an number of advisor activities defined based on the Avaya event stream and there is no 1:1 mapping for this to the T-server event stream.
As a workaround for the first phase of the project we have developed a custom Advisor desktop which allows us to set ACW codes via a ReasonCode in the extensions attribute of the Genesys CTI events. These are then picked up by some customisation in the Verint CSTI adapter.
However, in the next phase of the project we will be replacing the custom desktop with a vanilla SAP WebIC client and to set the ReasonCode would require major enhancements in SAP (and it not a good idea in terms of future releases).
Therefore, one alternative would be to develop a T-Lib server component that sits between the Verint CSTI adapter and the real T-Server component and ‘manipulates’ the CTI event stream accordingly based on an internal state machine (SCXML). This way we could use the standard Verint and SAP components OOTB.
As a proof of concept I decided to examine the T-library protocol based on some wireshark traces:
After some analysis and with reference to ‘tlibrary.h’ from the old C-based T-lib I think that I have worked out most of the protocol and put together some C# .NET code to test it:
The bottom line is (ignoring support and other commerical issues) that technically such a solution is possible. I’m not sure whether we will need to use this solution but thought that I would share my findings with you anyway.