Keeping track of agents extension number

Hey Guys

Long time CTI developer , but new to developing on Genesys. ( Used to install and configure Genesys back in 1999 , so it’s not totally new to me)

I’ve done a few integration projects.. latest one is to replace a failing solution. Solution provides a WS front end, where other parties can request a call to be made from agent X ( passing agent logon) to Number Y. The current solution is pretty hideous where for each request the service gets all dn’s from Config and then queries each one from TServer until it finds a match, grabs the DN and then sends the makecall request. ( It’s all in Java and does a few things which has me scratching my head!)

I’m replacing this with a Windows Service , so I can keep a state model of what agent is logged on where, so the requests can be processed without creating lots of load for each request.

Being playing around with approaches.. but not sure which is the best way.

a) Fetching all DN’s from Config , adding a request to monitor to TServer for all of them so I can keep a list of Agents / dns. Maybe poll Config every X minutes and check for new ones / removed ones. Worried about if the site uses dynamic monitoring , that I will be making TServer monitor everything and what implications that has

b) Is there a way I can use Stat server? ( potentially allot easier) Monitor all agents either via an Agent Group that covers everyone? Hopefully the DN is there for those stats? ( Haven’t looked, I’m still getting used to Stat server data and how to confirm whats there.. maybe the place data?)

I’m working on SDK 8.5 .NET

Any suggestions or concerns very much appreciated.

Thanks

Rob

Can you re-describe your current app? Can’t understand what it does exactly. WS is WebService?

Yes it’s a web service which allows other applications ( including web pages) to make a call for an agent.

For some reason ( I guess it’s legacy) the requesting client only knows the user name. Here are a few Java snippets

This happens for every get request.

Gets all dn’s from the configuration service

     Protocol pr = pms.getProtocol("cfgserver");

    KeyValueCollection filter = new KeyValueCollection();
    filter.addInt("dn_type", CfgDNType.CFGExtension.asInteger());

    RequestReadObjects rro = RequestReadObjects.create(
            CfgObjectType.CFGDN.asInteger(), filter);

then for each dn it queries TServer to get the details of that DN.

   if (!tsopened) {
        tso2 = initTserverConnection(pms);
    }

    Protocol pr = pms.getProtocol("tserver");        RequestQueryAddress rqa = RequestQueryAddress.create(dn,
            AddressType.DN, AddressInfoType.DNStatus);

Then grabs the agentid (after casting response to EventAddressInfo)

      id = eai.getAgentID()

and compares this to the username , if it matches then it uses that DN to request make the call.

    if (!tsopened) {
        tso2 = initTserverConnection(pms);
    }

    Protocol pr = pms.getProtocol("tserver");
    RequestRegisterAddress rra = RequestRegisterAddress.create(dn,
            RegisterMode.ModeShare, ControlMode.RegisterDefault,
            AddressType.DN);
    RequestMakeCall rmc = RequestMakeCall.create(dn, num,
            MakeCallType.Regular);
    RequestUnregisterAddress rua = RequestUnregisterAddress.create(dn,
            ControlMode.RegisterDefault);

    String message = "";
    try {
        pr.request(rra);

        pr.request(rmc);
        message = "<h3>MakeCall sent successfully</h3>";

        pr.request(rua);
    } catch (ProtocolException e) {
        log.info("WebCaller::makeCall ProtocolException: " + e.getMessage());
        log.error("WebCaller::makeCall", e);

        message = "<h3>ProtocolException</h3>";
    } catch (IllegalStateException e) {
        log.info("WebCaller::makeCall IllegalStateException: "
                + e.getMessage());
        log.error("WebCaller::makeCall", e);

        message = "<h3>IllegalStateException</h3>";
    }
    if (!tsopened && tso2) {
        closeGenesysConnections(false, true, pms);
    }

So rather than every call having to query every dn in TServer to find the right agent, I was hoping I could have a statistic from Stat server which will norify me of what agent has logged in or out of any DN, or worst case a single process that keeps track of the agents.

Actually I am now wondering if I can use Stat Server and peek a statistic passing the agent id and get the dn. ( or maybe I need to get the db id of the user first). ( I’m thinking out loud here

Many thanks for taking the time

Rob

Ahh , missed something in the existing java code ( I struggle a little to read it : )

There is another call to Config server to get the employeeID. I see that’s needed now.

Just tried another approach. ( not tested end to end)

If I get a ‘make call’ request for an user id that I have no record for, go to step 1 , otherwise fetch details from memory and go to step 5

1. I get the EmployeeID from config server. ( needed to create the statistic)

   Dim service As IConfService = ConfServiceFactory.CreateConfService(CSP)
   Dim query As New Queries.CfgFilterBasedQuery(CfgObjectType.CFGPerson)
   query.Filter.Add("user_name", username)
   Dim test As Object = service.RetrieveObject(query)
   

2. I create a new statistic “CurrentAgentState” for that user ( which will receive the logoff as an event in the future)

3. Get the DN from config server using the the place id that is provided in the return from creating the ‘CurrentAgentState’
   Update , seems like I need to fetch the cfgplace from config server , then fetch the DN from the config server using the dbid of the dn provided in the place. ( sheesh)

4. Store this agents details ( Agent ID, EmployeeID DN and the Statistic ID for the ‘CurrentAgentState’ statistic)

5. Make the call to TServer

6. Reply with result.

I would clear the statistics for any agent that has not had activity for more than X ( time) to make sure I am not left with old ones.

This seems a much better approach to the current solution.

Is there another way which is cleaner / less problematic?

Many thanks
Rob

Less problematic, no, as your requirement is kinda complex as well.
I guess this is a kinda dialer solution you are making, if so, why not just use OCS and maybe see its HTTP capabilities?

I am replacing a faulty component from an existing solution, therefore I don’t have the option to change the solution. I have to match the Web Service interface exactly so it just ‘slots’ in 8)

Looks like my new approach will work to me and be allot less load on things ( current component failing under load).

I’ll go ahead and build it next week.

Cheers

Rob

Hi Rob,

For the Statistics you could use a definition like this in StatServer:

Category = CurrentState
MainMask = *
Objects = Agent
Subject DNStatus

That will give you the Voice DN, Place and Switch that an Agent is logged onto:

‘EventInfo’ (‘2’)
message attributes:
REQ_ID [int] = 1
USER_REQ_ID [int] = 0
TM_SERVER [int] = 1455020597
TM_LENGTH [int] = 0
LONG_VALUE [int] = 0
VOID_VALUE [object] = AgentStatus {
AgentId = MCR_Agent0
AgentStatus = 8
Time = 1455020565
PlaceStatus = PlaceId = SIP_Server_Place3
PlaceStatus = 8
Time = 1455020565
DNs = DnCollection (size=2) [
[0] DnStatus {
ObjectType = Agent
DN Id = 7003
SwitchId = SIP_Switch
GSW DN TYPES = 1
DN Status = 8
Time = 1455020565
}
[1] DnStatus {
ObjectType = Agent
DN Id = chat
GSW DN TYPES = 0
DN Status = 8
Time = 1455020597
}
]
LoginId = 5000
}

You could also look at using RequestGetStatistic which will give you a one off event and then you don’t need to worry about closing any statistics after x seconds of inactivity:

"Requests one-time notification about a particular predefined statistic. Note, this request is not applicable to the CurrentTargetState category. "

Hope this helps,

Pete.

Hey Pete..

That’s fantastic advice, thank you. I will have a look at that approach today.

I am currently getting place info back from the Stat Server when I request the statistic, the place id is correct, but the DN’s is always empty. ( If I query the Place from config manager , i get the dn ids)

I will check out the statistic I am currently using , maybe it’s different.

Nice idea about the single stat, have to decide if it’s nicer to keep in memory and reduce the requests or keep it simple. I do like simple though 8)

Thanks so much, most appreciated.

Rob