Bulk Call Handler Create Utility
Select Call Handler To Use as a Template
Generate Extensions for new call handlers
Removing Handlers from the Grid
The Bulk Call Handler Create (or “BCHC” to the hipsters) is designed to create large numbers of call handlers in systems that need the ability for callers to dial phones not associated with subscribers. Unity is designed to only allow callers to dial Ids that are associated with objects in the directory and, as such, it’s not possible to allow them to dial just any extension they want to transfer to. Lots of reasons why it’s done this way but mostly it’s a security issue so callers can exploit holes in the voice mail to rip off long distance from companies using our products… kind of a touchy subject. That leaves sites that have hundreds of non subscriber extensions that they WOULD like callers to be able to access in a situation where they have to slog through the SA and do this one handler at a time… very annoying.
This tool allows you to select a call handler as a template and then create hundreds of copies of that handler that are customized to have different display names, extensions (optional) and transfer strings for the Alternate, Closed, and Standard transfer rules. You can enter these as a range of extensions or import extensions, display names and transfer strings from a CSV file (see below for details on the CSV file format). Once the grid is populated with all the call handlers you want to create, you can customize any or all of them and then hit the “create handlers” button and enjoy watching the progress bar plod along as it does all your dirty work.
A log is generated which will show the success/failure of the handler creation operations and a total error count will be provided at the end of the creation process. You should always check this log to make sure everything went as planned.
To use this tool basically work your way from the top to the bottom. First, select a handler to act as a template, then modify the options to your liking, add handlers to the grid, modify the grid entries if necessary then hit “create handlers”. Pretty straight forward but there are a few things to watch out for.
The first step to creating a bunch of call handlers is selecting a call handler to act as your template. Before you start, be sure to have configured a particular handler for this purpose which has all the settings you want on all the handlers you will create. The only properties that will be customized for each handler created are:
Display Name
Extension number (optional)
Alternate transfer string
Standard transfer string
Closed transfer string
Alternate Greeting (Optional from CSV file)
Standard Greeting (Optional from CSV file)
Internal Greeting (Optional from CSV file)
Busy Greeting (Optional from CSV file)
Closed Greeting (Optional from CSV file)
The After Greeting Action for each greeting can also be forced to send the caller to “attempt transfer” back to the call handler being created. This can be adjusted per greeting via the grid by checking/unchecking the “loop” options or via the CSV file input (see below).
All other properties will be copied over from the call handler you select as the template. This includes the voice name and the greetings (if greetings are not supplied via CSV). If the handler you choose has a transfer rule disabled, all call handlers created will have that same transfer rule disabled. You get the idea. Before creating a few hundred handlers, make SURE the handler you use as a template is setup exactly how you want it.
NOTE: The Bulk Handler Create utility will NOT activate transfer rules or greeting rules that are disabled. Even if you assign a transfer string and/or a greeting, that particular rule will only be active if it’s active in the template. You will need to go through and activate the rules you want after import. You can use the Bulk Edit utility off AnswerMonkey.net for this.
Once you select a template handler, you can add users to the grid and then import them. Prior to selecting a handler to use as a template the “create handlers” button is gray and if you select the “add handlers to grid” button, it’ll bark at you to select a template handler first.
The options you set in this box dictate what the call handlers added to the grid (in the next step) will look like. By default only the “base display name” property is filled in with the display name of the call handler you selected to use as a template.
The display name base is used to generate the new display names for all the call handlers added to the grid. The display name is generated using the text from this field and then tacking on the extension number to the end of it. You can adjust the display name for each handler in the grid after it’s populated if you want. If you’re importing from a CSV that’s providing display names, this value is not used.
By default the transfer string will simply be the extension number for the call handler. In cases where you want these to include a prefix (i.e. “9,” for outdial access) you’d enter this here. Again, this string will appear in the grid when it’s populated and you can adjust these values there before creating the call handlers. Again, if you’re importing from a CSV that’s providing transfer strings, this value is not used.
Since extension numbers are optional for call handlers, this checkbox is provided to indicate if you want to populate that field for the new call handlers or not. The extension number still gets used to generate the default display names and the transfer strings, however.
Before actually creating the handlers, you must first populate the grid so you can eyeball all the handlers that will be created and verify they look the way you want them to. The form is sizable so you can drag it out to see all the columns and the columns themselves are sortable, sizable and movable. So you should be able to make it look like you want to quickly look over the list of handlers you’re about to create.
The easiest way to quickly add a bunch of handlers to the grid is to provide a start and an ending value for an extension range and hitting “add handlers to grid”. You can add up to 1000 handlers to the grid at a time using this method, you’ll get an error if you try to add more. I added this limit more as a prevention of a user “fat finger” issue than anything else.
You can add several ranges to the grid and each range can have a different set of options configured, however all new handlers will use the same call handler as it’s template. If you want to use different templates for different sets of handlers, you will need to run this tool multiple times.
You can import handler information from a CSV file. The “Extension” field is required but you can also import display name and transfer string information as well. See the “CSV Format” section below for details on the file format requirements.
NOTE: If you attempt to add another group of handlers to the grid and one or more of them conflict with extensions already added, you’ll see an error dialog pop up telling you this. The conflicting handlers wont be added to the grid, but all other handlers will. This is true for adding handlers via a range of extensions or from a CSV file.
Once items are in the grid you can edit all the cells individually to customize display names, transfer strings etc… on a handler by handler basis.
To remove handlers from the grid simply select the check box in the far left column of the grid and hit the “remove selected” button at the bottom left of the grid itself. If you need to empty the grid and start over, just hit the “clear grid” button at the bottom of the grid.
Once you have the grid populated with all the call handlers you want to create and everything looks good, hit the “create handlers” button in the lower left and let it do it’s thing.
All new call handlers will be created with an alias that is generated with this format:
“<display name><extension>_<systemID>_<seconds from midnight>”
The seconds from midnight ensures uniqueness if you’re running this tool a LOT on a system.
If there are any extension conflicts with existing call handlers in the system, an error will be logged to the output file and that handler will be skipped in the creation process. Testing on several boxes shows this takes 2 to 5 seconds per handler (depending on hardware being used) so it should move along fairly quickly.
One of the methods of populating the grid with call handler extensions you wish to create is browsing to a CSV file and creating those handlers based on their extension. The format of the CSV file only needs to follow two rules:
1. The values need to be separated by commas. Tab or CrLf or semicolon separated files will not be parsed correctly.
2. It needs to include a column header in the first line of “extension”. This is not case sensitive and can be padded on the left or right (or both) with spaces.
It can optionally contain any or all of the following columns:
DisplayName – If a display name is not
supplied it’ll be generated using the display name provided on the form (from
the template handler) and the extension number.
TransferString – Be sure this transfer
string contains no commas. You can add
prefix digits such as “9,” using the interface on the Bulk Handler Create tool
itself during import. This populate the
transfer string for the standard contact rule. If it’s blank the transfer
string (if any) from the template used will be left alone. If a string is passed in the rule is forced
to enable transfer.
AlternateTransferString – Again, be sure
the transfer string contains no commas – this populates the transfer string for
the alternate contact rule. If it’s
blank the transfer string (if any) from the template used will be left alone. If a string is passed in the rule is forced
to enable transfer.
OffHoursTransferString. Again, be sure
the transfer string contains no commas – this populates the transfer string for
the off hours contact rule. If it’s
blank the transfer string (if any) from the template used will be left
alone. If a string is passed in the rule
is forced to enable transfer.
StandardGreetingPath – This can be a hard
coded path to a WAV file that will get pulled in as the standard greeting for
the call handler. It can also be just the
WAV file name if the WAV file is copied into the same directory that Bulk
Handler Create is running from. This can
sometimes make generating the CSV files a bit easier. Note that these WAV files names will be
converted into standard Unity format (“<Alias><greeting
name><unique number>.wav”) when they are pulled in.
OffHoursGreetingPath – WAV file for the
off hours greeting for the call handler
AlternateGreetingPath – WAV file for the
alternate greeting
BusyGreetingPath – WAV file for the busy
greeting
InternalGreetingpath – WAV file for the
internal greeting
LoopStandardGreeting – If you set this to
1 it’ll force the after greeting action to be to “attempt transfer for” the
call handler being created. Any other
value or blank will leave the after greeting action set to whatever is provided
in the template.
LoopOffHoursGreeting – If you set this to
1 it’ll force the after greeting action to be to “attempt transfer for” the
call handler being created. Any other
value or blank will leave the after greeting action set to whatever is provided
in the template.
LoopAlternateGreeting – If you set this
to 1 it’ll force the after greeting action to be to “attempt transfer for” the
call handler being created. Any other
value or blank will leave the after greeting action set to whatever is provided
in the template.
LoopBusyGreeting – If you set this to 1
it’ll force the after greeting action to be to “attempt transfer for” the call
handler being created. Any other value
or blank will leave the after greeting action set to whatever is provided in
the template.
LoopInternalGreeting – If you set this to
1 it’ll force the after greeting action to be to “attempt transfer for” the
call handler being created. Any other
value or blank will leave the after greeting action set to whatever is provided
in the template.
LoopErrorGreeting – If you set this to 1
it’ll force the after greeting action to be to “attempt transfer for” the call
handler being created. Any other value
or blank will leave the after greeting action set to whatever is provided in
the template.
All other columns will simply be ignored. For instance, a file that starts like this will be parsed without a problem:
First Name, last Name, displayName, home server, Alias, extension, manager, domain, transferString, AlternateTransferString, LoopErrorGreeting
Jeff, Lindborg, Answer Monkey, EXServer1, jlindborg,1189,Tom Wesselman, ENG_MAIN, 5253189,,1
John, Smith, John Smith, Exserver7, jsmith,7784,,ENG_LAB,5257784,449193,1
...
Each row of the CSV file will be read in and the corresponding column that contains “extension” in the first line (column #6 above) will be used to pull the extension string out of that line. If the extension is not all numbers or is too long (9 characters max for my app) or is missing, that row will be skipped and nothing will be added to the grid. If a valid extension is found, the display name and transfer string columns will be searched for if defined. Optional columns that contain full path names to WAV files for the standard, off hours, busy, internal and/or alternate greetings of the call handler can be provided as well.
NOTE: It’s perfectly legal to only import extension information. The same method for constructing display names and transfer strings used for the extension range creation method noted above will be used to populate the grid.
NOTE: If you choose to not check the “Generate Extensions for new call handlers” box in the options section, these users will be added to the grid without extension numbers. The extension number from the CSV file will be used in generating the call handler’s display name and for the default transfer strings for all three contact rules, however.
NOTE: If you’re importing greeting wav files, it’s a good idea to level your greetings and voice names to be the same dB. If you’re running on Unity 3.1(1) or later, you can use the “Set Volume” utility off AnswerMonkey.net to do this.
To check for updates to this tool, visit http://www.CiscoUnityTools.com
Version 2.0.7 – 3/3/2004
Force messaging rules cursor to be client side
instead of the default server side to avoid problems with failover replication
while updating data. CSCed82998
Version 2.0.6 – 11/18/2003
Fixed automatic display name generation when CSV
file did not include any name fields but only an extension column
Fixed problem where contact rule was not being
forced to enabled when a transfer string was explicitly set in the grid for
that rule
Version 2.0.5 – 10/31/2003
Fixed file parsing error causing a “one off”
column reference in some scenarios
Version 2.0.4 –10/29/2003
Added support for forcing after greeting action
to loop back to PHTransfer entry point for parent call handler for each greeting
separately via CSV or the grid input.
Added support for populating the alternate and
off hours contact transfer strings from CSV.
Changed logic for enabling transfer action – if
the transfer string is forced from CSV or the grid the action is set to transfer
automatically regardless of what the template’s contact rule is set for.
The transfer strings are left empty if not
populated from CSV instead of being forced to the extension by default.
Version 2.0.3
Updated setup with new fixes for the MS install
package
Updated help file
Version 2.0.2
Fixed problem where avp_is_primary flag was
being left as null in some cases, force it to 0 all the time
Fixed problem where path to WAV file for
greetings was not being parsed properly
Version 2.0.1
Updated for 3.x specific functionality
Added support for pulling in call handler
greetings via CSV
Version 1.0.34
First public version of tool
© 2003 Cisco Systems, Inc. --
Company Confidential