Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Vic on January 01, 1970, 12:00:00 AM
-
Has anyone ran into a problem trying to load a campaign on OCS 6.5 and getting "Outbound campaign group not found error code 9"?
-
Ok,
I figured what this was OCS server seems to be having a bug where if it loses connection with the TServer, the campaign status gets really messed up. I had to restart my OCS server and then everything worked fine...
-
Anyone who experienced the same in OCS 7.5? I configured some new campaigns once more, but when now starting OCM I get error message 9 (Campaign Group not found) and error message 13 (Campaign Sequence Not Found), until I deleted these new campaigns.
Kind regards,
andre
-
Changed CME lately? :)
-
No. It is also possible to add this campaign in our testenvironment, where the same parameters are in place. The only difference between test and production is the amount of campaigns we are running.
-
Which DB are you using? I faced a similar issue with MSSQL because the "smart" customer guy gave us a low profile DB so when we started with OCS it died...upgraded to enterprise and solved the issue.
-
AFAIK oracle 10i is in use...
However in OCM you can see the campaign after removing the error messages, but afterwards the new campaign is in status 'unknown'. all others (former) are in state running or unloaded...
regards,
andre
-
What does OCS DBserver tells you? Please posts the logs for it.
-
Nothing suspicious in DB-Server logfiles for OCS. Do you have something on your mind you expect?
I don't like to paste the complete logfile here. What I encountered is that the new campaigns can't be found in current logfiles when I start OCM, neither in config-dbserver nor in ocs-dbserver (searched by campaign name and by database-ids).
regards,
andre
-
We have some new results: When viewing the database, we have the capability to view some stats for each table, amongst others "num_rows". for ocs-table this value is not identical to the actual number of rows we can see when looking at the real data. it does exactly show the value before inserting the new campaigns, so we think we have to analyze there furthermore, which is not done by me.
kind regards and thanks for your support,
andre
-
My last post seems not to be valid, because those stats are updated after each 'analyze', but has nothing to do with the real data of a table, but only for internal oracle mechanisms regarding performance. So it seems not to be the cause for my problem.
regards,
andre
-
Do you get those messages for any campaign? Or any new added? What's the difference between existing campaign and these new ones? Which user are you using to log in OCM?
Fra
-
Error messages appear only for new campaigns, and I am using the same user like before, nevertheless the error occurs to evreyone who is logging in. Besides this the campaigns have been deleted and added again by someone else with the same result.
regards,
andre
-
And what about a little test, create a new db, a new db server, make sure the dbserver is compatible with your oracle version, create a new calling list but using this new dbserver and compare the results.
-
That is not possible, it is our productive environment. For each installation I have to go through an installation process with the operator, that takes weeks.
regards,
andre
-
I think the only way to get down to the issue is to post some log files:
1. confserv: during campaign creation
2. ocsserver: at startup
3. confserv, ocsdbserver and ocsserver: when you start OCM
If you can't post them, we can just make causes up..
-
Agree with Fra, without seeing what is really going on through logs we can't really help too much...we are just guessing over N possible causes.
-
Thanks for your support and excuse my delay. In the meantime we upgraded to ocs 7.6 (because of some other major issues it was done so fast) and this problem disappeared!
kind regards,
andre
-
Cavagnaro,
may you lend me your avatar to express my bewilderment? ??? ;D
-
Well, I feel the same so often with Genesys... Using the former version it was necessary after each restart of OCS to restart all T-Servers... That seems to be obsolete now, too...
-
[quote author=Fra link=topic=928.msg13369#msg13369 date=1219064555]
Cavagnaro,
may you lend me your avatar to express my bewilderment? ??? ;D
[/quote]
;D haha yes you may, one scratching his head would be more appropiate I think so... :P
I don't see any related bug on the fixes...very strange
-
Hello All,
I think the issue was in the Agent group definition used for particular campaign. I bet that the origination dn was not set properly. However this is not relevant anymore as 7.6 quite different.
Cheers.
ecki.
-
I have seen this issue many, many times and there has only ever been 1 reason. Error Code 9 is very specific in my experience, although there is no listing that I know of that provides a description of what these error codes are that I've ever been able to find.
It is almost always caused by the OCS not being connected to the TServer that relates to the Agent Group/Origination DN that is specified in the campaign. Meaning the OCS cannot monitor the agents that you are attempting to deliver to. In our environment we run 6 separate OCS's so this happens quite regularly.
If this is not the case then I would assume that the Origination DN for the agent group is not registered correctly with the PABX, thus causing the same symptom. In this case you will need to delete and recreate the DN.
-
hmmm... we have for all campaigns the same origination dn at each location, and all other campaigns were running fine. so the dn was registered fine i think.
-
[quote author=astrakid link=topic=928.msg13707#msg13707 date=1220945795]
we have for all campaigns the same origination dn at each location
[/quote]
Location? By the way, origination DNs should not be shared..
-
well, we have for each location its own campaign, all combined to one campaign group. because of a lower delay in call delivery we had to have each location work physically independent from other locations.
regards,
andre
-
So... many Genesys campaigns sharing a single agent group?
If that is correct then each Genesys campaign will see the calls that are delivered for the other campaigns as inbound volume. This will cause long wait times between calls due to the OCS being designed to prioritise inbound volume. Worth looking into I think.
But of course that's not the question, the question is around error code 9.
I've searched a few tickets on the Genesys support site and all of them have the same cause of this error.
The OCS has no connection to the TServer that the campaign is dialling for. There are many potential causes for the connection not being made, but it's always the same underlying reason for the error itself.
But of course, now that you're running 7.6 it's a redundant question by the sound of it.
-
Ok, thanks for the hint.
The other part of your posting is as interesting for me as the answered one:
We are using for each location its own virtual agent group, but nevertheless we were facing too high waiting times. But unfortunately I'm not involved in current investigation.
Kind regards,
andre
-
Actually not really clear to me...can you be a little more clear?
With location do you mean site\switch (then you have a multisite enviroment)?
Do you have one origination DN per site? If you have one OCS and multiple TServer, where, it might be a registration problem.
-
yes, multisite, and each site has its own origination dn.
-
Provided it's 1 agent group object = 1 origination DN and the calls delivered to that agent group (both outbound and inbound) come through that origination DN it should be ok.
-
we have separated inbound and outbound completely, so outbound agents are only performing outbound.
regards,
andre