2016년에는 제품 기능개선과 CMZ 사항을 추가된 기능으로 포함시켰으나 넥서스커뮤니티 내부에서 개선된 사항은 제품 기능개선으로 고객의 CMZ 요구사항으로 인한 추가기능으로 구분합니다.

제품 기능개선은 넥서스커뮤니티가 고객이 요구하기 앞서 우리가 제품향상을 위해 노력하는 부분입니다.

2017년 12월 릴리즈(2.7.12) 에 반영 예정중인 기능

1. 쿼리툴(쿼리를 직접 넣어 data 를 확인 할 수 있는 툴)

2. high level api 개발

3. 연간스케쥴 적용 개발

4. 사용자정의 라우트현황창

기존 .netframework 버젼과 구별하기 위해 patch 번호 부여가 구분됩니다.

.netframework 2.0 의 경우는 2.7.10.00 으로 표시됩니다.

.netframework 4.6.1 부터는 2.7.11.40000 표시됩니다.

setfeature의 reason code 100 일때( cubeEmergencySetFeature ) media 자체적으로 로그오프 이벤트를 생성하고, pbx에도 명령이 전달되도록 작업

메뉴ID 47번 할입감청 기능 사용

1) 시나리오 로딩 시 전체범위의 날짜를 로딩하거나 원하는 날짜범위의 날짜만 로딩할 수 있다.

2) 원하는 날짜범위의 기간스케쥴을 삭제할 수 있다.

3) 접속 시마다 삭제(기본값 한달 by note2)는 본 기능에서 제외하고, 2)의 기능만을 유지한다.

자원로딩시 기간스케줄 로딩 범위 설정 및 기간스케줄 범위 단위 삭제 기능 추가(제품ID 3 메뉴ID 13)

① S 실행 시 로딩 방식을 설정하는 부분

- 전체 : 기존과 동일한 방식으로 기간스케줄 전체를 로딩한다.

- 범위 : 시작날짜와 종료날짜를 설정하여 해당하는 범위의 기간 스케줄만 로딩한다.

② 기간 스케줄을 범위 단위로 삭제하는 부분

- 시작날짜와 종료날짜를 설정하여 해당하는 범위의 기간 스케줄을 삭제한다.

③ 설정 또는 삭제 시 메세지를 표현하는 부분

설정방법

process.conf

[nxstate]

abcall-list-save = on # off / on

abcall-list-file = /home/cube/nexus/products/cube/abcall-list

[작업내용]

1. 포기호 정보(고객번호, 포기횟수, 직전포기큐, 직전포기시간, 총포기시간)을 nxstate 로컬 메모리에 보관한다.

2. 보관된 정보는 날짜가 변경되거나, 동일한 ANI 번호로 분배가 되면 삭제된다.

3. nxcapiGetAbandoncallinfo api 를 호출하여 ANI에 대한 포기호 정보를 가져올수있다.

4. 'abcallinfo' 문법을 사용하여 시나리오에서 ANI에 대한 포기횟수, 직전포기시간을 가져올수있다.

[시나리오 포기호 라우팅 테스트문법]

abcallinfo[AB=ANI]

( AB.count > 7) goto AAA

(( AB.count < 7 ) and (AB.count > 4 )) goto BBB

( AB.beforetime < 360 ) goto CCC

wait[5]

1->[100.0]

bookmark AAA

Priority = "A"

1->[100.0]

bookmark BBB

Priority = "B"

1->[100.0]

bookmark CCC

Priority = "C"

1->[100.0]

<mysql>

정상

[22:50:12.434][adb.c,14][3]<allocateContextFree><ERROR_CODE :[ 1 ]>

DB 종료

[22:51:59.321][adb.c,14][3]<allocateContextFree><ERROR_CODE :[ 2003 ]>

<mariadb>

정상

[09:51:48.953][adb.c,12][3]<allocate_Context ><ERROR_CODE :[ 1 ]>

DB 종료

[09:55:32.800][adb.c,12][3]<allocate_Context ><ERROR_CODE :[ 2003 ]>

<ORACLE>

정상

[11:33:16.126][adb.c,12][3]<allocate_Context ><ERROR_CODE :[ 1 ]>

DB 종료

[11:42:06.231][adb.c,12][3]<allocate_Context ><ERROR_CODE :[ -1090 ]>

<SYBASE>

정상

[18:09:30.814][adb.c,12][3]<allocate_Context ><ERROR_CODE :[ 1 ]>

DB 종료

[18:15:30.814][adb.c,12][3]<allocate_Context ><ERROR_CODE :[ 0 ]

[cube@release bin]$ prtroute -w

===========================

|Rep Name | Cur / Max |

---------------------------

|Route | 2 / 150 |

---------------------------

#--------------------------------------------------------------------#

1. route kind type wait sum avg ewt longest

#--------------------------------------------------------------------#

[1] cnid[2608000022] cid[10127] ani[2042] wtime[9]

[001] 3/10/6241 4 1 1* 0 0 30* 9

++ atime:07-11 10:00 scen:(2)분배_POW

++ en:1 ens:0 dv:0-1 at:0-0-0-0-0-0-0 at[exp]:0-0 ab:0 ns:0 fl:0 ed:0 ea:0 tr:0 cb:0 rto:0 rtf:0 rfm:0 ext:0 re:0 rea:0 lwt:100 lrs:20 ++

++ match:0 nacd:0 dskill:0

++ monitor result(1)

설정방법

process.conf

[nxstate]

call-limit-time = 10800

범위는 최소값 1시간에서 최대값 6시간 입니다. 따라서 3600~21600초로 설정할 수 있습니다.

기본은 10800초(3시간) 입니다.

routing session은 콜 이벤트, 상담원 추가, 변경, 삭제, 시나리오 이벤트를 받고 호를 분배요청하는 session 입니다.

sync session은 oid 에 사용되는 공유메모리 동기화 및 초기 master 데이터 송수신 부분 session 입니다.

이 두개의 session 상태를 확인 할수 있으며, 총 4개의 상태가 있습니다.

down : 연결이 끊겨있으며, 접속 시도하지 않는 상태입니다.

trying : 연결은 끊겨있으나, 접속을 시도하는 상태입니다.

connected : 연결은 되었으나, 서비스에 필요한 정보를 송수신하지 않은 상태입니다.

servriceok : 연결이 되었으며, 서비스에 필요한 정보를 송수신하였습니다.

exdetail에 나타나는 항목은 엔진시작시 process.conf의 [nxlistener] 항목을 읽어서 사용합니다.

routing::{ ::count:3{

00 = { uptime=2017-06-05 14:38:19 ip=121.170.212.196:9700 state:ready }

01 = { uptime=2017-06-07 11:06:50 ip=121.170.212.195:9700 state:ready }

02 = { uptime=2017-06-05 14:35:47 ip=121.170.212.181:9700 state:active }

}

exdetail::{

conf count:3 {

00 = { nxlistener 1200 -> center=2 routing=121.170.212.181:9799 serviceok

sync =121.170.212.181:9798 serviceok

extsnyc=2017-06-05 14:47:19

}

01 = { nxlistener 1200 -> center=1 routing=121.170.212.196:9799 serviceok

sync =121.170.212.196:9798 serviceok

extsnyc=2017-06-05 14:47:19

}

02 = { nxlistener 1200 -> center=1 routing=121.170.212.195:9799 serviceok

sync =121.170.212.195:9798 serviceok

extsnyc=0000-00-00 00:00:00

}

}

사전조건

DB MA_VERSION 테이블에서 v2.7.10 이상으로 표시되어야 합니다.

VW_DALIST.SQL 뷰가 추가되어야 합니다.

CUBE M 권한 31번 입니다.

CUBA A 권한은 43번 입니다.

설정방법은 EXD-01.INF 에서 다음 옵션 설정시 사용가능합니다.

[OPTION]

USE_CIDS_GROUP=1

[SHAREDMEMORY]

SMCIDSGROUP=50022, SMCIDSGROUPSIZE=100

5000명 성능 테스트 결과 30% 정도 향상되었습니다.

Petra 암호화 사이트 Recovery 방법(원문 -> 암호화 하여 입력시)

Petra 암호화 사용하는 고객사에서 암호화 문제 발생시 Recovery 방법입니다.

(다른 암호화도 Recovery 방법은 동일 하나 추가 작업은 필요합니다)

EXD-01.INF에서 아래 설정을 통해 통계 파일(CmRlt)과 Database에 암호화 설정을 할수 있습니다.

encryption.file.field = telno,custkey,

encryption.db.field = telno,tkda

encryption.file.type = petra

encryption.db.type = petra

그러면 엔진에서는 데이터를 Petra 암호화 상태로 데이터를 쌓게 되는데, 다음 케이스와 같이 암호화가 끊어진 경우가 발생할수 있습니다.

1. 엔진 시작시 Petra 암호화 연결이 안되는 경우

2. 엔진 사용중 상태에서 Petra 암호화 연결이 끊어지는 경우

이때, 엔진에서는 DBFILE과 Database에 대해 원문으로 데이터를 쌓게 되며, 끊어진 시점부터 .PETRA 형태로 추가적인 DBFILE을 생성합니다.

예) CmRlt-1-20170710.PETRA

암호화가 정상이 되면 다시 암호화 형태로 데이터를 쌓게 되는데, 추후 원문으로 쌓인 데이터에 대해 Recovery를 해야 합니다.

Recovery시는 .PETRA 파일을 가지고 원문으로 쌓인 CmRlt 파일과 Database를 변경 할수 있습니다.

단, EXD-01.INF에 설정된 내용을 읽어다가 Recovery하기에 설정 옵션을 바꾸면 안되며, 당일은 복구는 불가합니다.

다음과 같이 EXD-01.INF에 암호화가 설정된 상태에서

encryption.file.field = telno,custkey

encryption.db.field = telno,tkda

encryption.file.type = petra

encryption.db.type = petra

다음 명령으로 Recovery 실행하게 되는데

복구 실행 : EXDfr 01 RECOVERY ./FILE/CmRlt-1-20170709.PETRA

Recovery 성공시 CmRlt 파일에 대해서는 Telno, Custkey에 대해서 암호화 되어 파일이 변경되며,

DB에 대해서는 Telno, Tkda에 대해서 암호화 되며, .PETRA 파일은 그대로 보존됩니다.

Recovery 후에는 데이터 정상 여부를 확인한 다음에 .PETRA 파일을 삭제 하시기 바랍니다.(고객 정보가 원문으로 남아 있음)

대략적인 patch 개수 250여개 입니다.

버젼별 이슈를 포함시키면 300여개 입니다.

엔진 NEXUSCUBE v2.7.10.63

엔진 NEXUSCUBE v3.0.2.51

DB NEXUSCUBE v2.7.10.2

DB NEXUSCUBE v3.0.2.2

NEXUSCUBE-M v2.7.10.3

NEXUSUCBE-P v2.7.10.5

NEXUSUCBE-I v2.7.10.30

NEXUSUCBE-R v2.7.10.24

NEXUSUCBE-A v2.7.10.20

NEXUSUCBE-S v2.7.10.7

NEXUSCUBE-C v2.7.10.13