Contents

Handler Standards

This topic describes the standards that were used in creating the handlers that shipped with CIC. We highly recommend adopting these standards when creating your own handlers.

Variables (locally scoped)

Variables have been named using a convention similar to Hungarian notation. Each variable name has a prefix indicating the data type in lowercase followed by the variable name. Except for native data types, many relate to data structures and so are unique to handlers.

The following table outlines data type prefixes for native data types.

Data Type	Notation	Example
Integer	i	iCount
Numeric (double)	n	nPayRate
Boolean	b	bSuccess
String	S	sName

The following table lists the data type prefixes for external data types. For each of these types there is a corresponding list data type. Any list data type starts with an l (lowercase L), followed by the type abbreviation. For example, the Mail Folder data type (e.g., mfSysAdminAccounts) has a corresponding List Mail Folder data type (e.g., lmfSysAdminAccounts).

Data Type	Notation	Example
Accumulator Lock Key	aclckkey	aclckkeyTimeout
aQueuePeriodStatictics	aqprdstat	aqprdstatTimeout
Calendar ID	cal	calApril
Call ID	Interaction	Interaction1
Conference ID	conf	confFollowMeCall
Database	db	dbCustomerData
Date Time	dt	dtTomorrow
DB Connection	dbconn	dbconnSQLSever
Diagnostic Data	dd	ddErrorMsg
EntryHdl	enth	enthTemp
EntryListHdl	entlsth	entlsthTemp
FaxEnvelopeID	faxenv	faxenvSend
FaxFileId	faxfile	faxfileIncomingFax
FaxObjectId	faxobj	faxobjTempFax
FaxPageListId	faxpglst	faxpglstProductListing
File Handle	fileh	filehTempData
Host Interface Connection	hst	hstMainFrame
Lock Handle	lckh	lckhThisLock
LoginHdl	logh	loghICUser
Mail Folder	mf	mfSentItems
MQ Connection	mqcon	mqconReportingQueue
MQ Object	mqobj	mqobjReortingObject
OperationListHdl	oplsth	oplsthTemp
Prompt	prmpt	prmptHello
Recording	rec	recConfCall
RequestHandle	reqh	reqhTemp
Semphore Lock Handle	semlckh	semlckhTemp
Sequence	seq	seqTemp
Session	sess	sessTemp
SessionHdl	sesh	seshtemp
SOAP Request	soap	soapTemp
SocketHandle	sockh	sockhTCPConenction
String	s	sName
UMF Message	umf	umfIncoming
Web Connection	webconn	webconnCustomerOrder
XML Node	xmlnode	xmlnodeUserInfo
XML Node Iterator	xmlnodeit	xmlnodeitProducts

Note that the Call ID variable does not follow the normal convention. This is intentional. Because all the xIC product lines focus on processing interactions, this one variable is spelled out.

Variables (globally scoped)

Any globally scoped variables starts with g_ to denote that it is global, and are followed by the lowercase data type indicator. For example: g_iUsersLoggedIn

GET and SET subroutines should be written for each global variable. This is because handlers that access a global variable place a lock on that variable for the time period that the handler is in scope. By creating these separate subroutines, the lock will only be on the global variable for the shortest possible amount of time, allowing other handlers to access it more easily.

Subroutines

All handlers that start with an initiator other than the subroutine initiator should be named with this prefix: "System_" In addition, the name of the handler should be in a mixed case, capitalizing the first character of each word. For example: System_IncomingCall.ihd

Any parameter (either input or output) to a subroutine should be named with a "p_" prefix. This allows anyone looking at the handler to immediately know that this variable is a parameter to a subroutine. For example: p_Interaction1

Each subroutine should have a Boolean variable defined as bTransferred that is set to show whether the interaction is terminated in this handler (False) or continues on (True).

Prompts

All fields within the Prompt Editor should be filled out: Prompt Name, Description, Chat Text, TTY Text.

In naming prompts, the names should be written in all uppercase with a suffix containing the language abbreviation. For example, HELLOWORLD_ENUS.

General Layout

Handlers with tightly grouped or overlapping steps, links going in seemingly random directions, and unused tools are very hard for others to read and debug. Sloppy handlers are also more likely to contain errors. While we do not want to dictate specific logic flow, we do highly recommend following these general guidelines concerning layout:

Never allow links to flow through a tool step. Either move the steps to make more space, or re-route the link lines so that they go around, instead of through, the intervening steps.
Do not bunch tools together; make sure there is plenty of white space between the tools. If you are modifying a handler and need to make room for new steps, drag out the other tools to make space; do not just squeeze the tools in. Make use of the zoom feature to grab and move large groups of tools if you need to make room for new steps.
All label fields on tool steps should be filled out. For example, assignment steps should have the variable name they are assigning in the label, like "sUserName." Condition steps should give some indication of what is being evaluated, such as "Success=TRUE?" or "iCount >= # of Users?," etc.
Drag all tool steps out wide enough that the Tool Name and Tool label are completely visible. The only exceptions to this might be the selection tool that could contain very wide case elements, but even this can be widened completely in most cases.
Align your steps. If you have a number of tool steps that flow right to left, up to down, or whatever direction, align them so they look nice. The alignment buttons in the layout toolbar make this a simple task.
Add notes as needed. If you are doing something that might seem odd or ambiguous to others, fill out the notes field to explain what you are doing. For example, a note might explain that a set of tools is intended to work around a bug in LDAP. Prefix the tool's label with the word, "NOTE:" to let others know that there is more information in the tool's properties page.
The description field of initiators should list any customization points in that handler.
When you are finished developing a handler, ensure only the variables being used are present in the handler by selecting all of the unused variables in the Variable viewer and deleting them.