In this chapter I assume you already have a good understanding of the
basic architecture and data object model for Unity. If you haven't
already done so I strongly encourage you to read the Architecture
Overview and Data Object Model chapters before proceeding. It's also
a good idea to cover the Audio Text Applications chapter since that
gives you some in depth coverage of how call handlers and subscribers
are related and interact in the system which is important if you want
to do anything beyond simply creating and deleting subscribers.
Complete working versions of all the examples we'll cover in this
chapter are available for download from the "Code Samples" page at
www.CiscoUnityTools.com. These are all done in VB 6.0 projects
however if you don't have Visual Basic you can still open the forms
and modules with a text editor to review them if you like. I will be
reproducing only small chunks of source in this chapter, I highly
recommend you get the entire sample applications and look through
them. Once Unity starts shipping with the full .NET framework
included on the box and, more to the point, testing is completed with
those files under load, I'll update the code samples site with some
VB.NET versions of the same samples. That said, the mechanisms used
here are not really language specific since they concentrate almost
entirely on accessing SQL databases and using stored procedures and
views which just about any language is capable of.
While you're out on CiscoUnityTools.com I also highly recommend you
get the latest version of the Cisco Unity Data Link Explorer (CUDLE)
application. This tool started shipping with 4.0(1) however you'll
want to get the latest version and check back often for updates. I
specifically designed this tool for use by folks developing
applications against Unity's SQL database.
Information about what data is stored in the SQL database tables and
columns, what's in the registry and details on the stored procedures
used for programmatic administration (including the full source for
all stored procedures) are updated and added often in this tool. The
built in data dictionary for SQL in particular is very useful for
developers getting started with Unity and throughout I assume you have
access to this for looking up what values for a particular column
mean. For instance in the screen shot above the AfterMessageAction
values are enumerated and explained in the "column info" tab . CUDLE
also has it's own Query Builder in it for folks that are not using the
full SQL 2000 install and don't have the SQL Query Builder at their
disposal. You'll definitely want to have one or the other handy as
you work out the queries you need to pull data from the UnityDB
database. One last plug for CUDLE: all the columns in all the tables
are listed alphabetically which makes it much easier to find what
you're looking for. The SQL Enterprise manager, for reasons that
boggle the mind, shows columns in the order in which the creation
scripts add them which for large tables makes stumbling around trying
to find something difficult at times. All the cool kids use CUDLE.
C'mon, first time's free.
Of course you'll also need a running copy of Unity 4.0(1) or later. I
highly encourage you to make sure you have 4.0(3) or later as some
functions discussed in this chapter were not active in 4.0(1) or
4.0(2). You can download versions of Unity 4.0 off of the Cisco
Software Center site. All versions of Unity include a limited
"demonstration license" that will allow you to install it and test
against 2 ports and up to 10 users. Record time for messages is
limited to be sure it's not used in (very small) production
environments and features such as AMIS or VPIM are not active. If you
need more users and a "full production test" environment you can apply
for a free temporary license that will time out in 30, 60 or 90 days.
Information and links for these licenses can be found on the "Links"
page of www.CiscoUnityTools.com.
What We'll Cover
There's a lot you can do fiddling around in the database directly with
Unity, of course, however we'll be concentrating on the most necessary
items in this chapter. Namely we'll walk through how to find and
connect to remote Unity servers, get necessary information off of them
for report type applications, how to create, import, modify and
delete subscribers as well as creating and adding new members to
public distribution lists.
The vast majority of what folks ask me about is how to plug Unity into
their existing provisioning systems which involves the creation,
deletion and modification of subscribers in the Unity database.
Surprisingly enough I don't get a lot of requests about how to
automate the construction of interview handlers. There are stored
procedures for doing just that, however, and over time there will be
more sample applications added to www.CiscoUnityTools.com. If you
have items you'd like to see covered, be sure to ping me at the
address off the web site and I'll try and accommodate you. However in
this chapter we'll stay focused mostly on subscribers.
A Word about APIs and Support
For Unity 4.0(x) the only mechanism available for administering Unity
programmatically is direct connections to the SQL database on the
Unity server in question. We will be using views for reads and
queries and stored procedures for updates such that folks using them
will be isolated from changes to the actual data structures behind the
scenes. If you don't know what a "view" or a "stored procedure" is,
you really should get yourself an introductory book on SQL before
going too much further. I'll provide enough detail for you here to
stumble around if you're not familiar with SQL, but to get the most
out of this, it's a real good idea to get some of the basics under
your belt. This chapter assumes at least a beginner's level of
familiarity with SQL concepts.
My weapon of choice is Visual Basic 6 with service pack 5 using ADO to
do the dirty work connecting to SQL, however you can pick whatever set
of tools paints your wagon. All the code samples and projects in this
chapter and on the CiscoUnityTools.com website are in VB 6 since this
is primarily what I work in and the code is very easy to read. I've
had a few C++ programmers complain that I don't have any source code
samples for them to work off of and my thought on that is if a big,
strong C++ programmer can't figure out what my simple, brute-force,
well-commented VB code is doing you've got much larger problems to
deal with in your professional life. You should be able to apply the
concepts laid out here to whatever tools you prefer to use without too
much trouble I'd hope since the vast majority of the logic involved is
dealing directly with SQL queries and executing stored procedures
which can be done in just about any language available.
Before getting too much further, it should be made clear that nothing
in this chapter is supported directly by TAC. There will be no
official support for remote programmatic administration of Unity in
4.0(x) either from TAC or the engineering group responsible for Unity
(the Enterprise Communications Software Business Unit - ECSBU). Such
support will be there for the provisioning API(s) that will be
included with the next major release of Unity code named "Kubrick".
There's no release date or committed feature set at the time of this
writing so I can't even ballpark when this will be available to the
public, but I can tell you it's being worked on. I also can't tell
you what form those provisioning API(s) will be in, but they will very
likely include a SOAP type interface that essentially wraps the SQL
functionality we'll be discussing in addition to direct SQL
connectivity that we'll be working through here. There is not going
to be a custom, proprietary interface provided as an API, the work
will revolve around what we cover here and the logic will remain
largely the same. The primary difference will be in mechanisms that
allow you to attach and execute queries and procedures remotely.
That said, what's discussed here will continue to work moving forward
regardless of what other APIs and connectivity methods are provided to
the public. If you're like me, I like to get down to the real data
rather than have a high level wrapper abstract it out from under me.
While wrappers can make things easier in many ways and are ideal for
many types of operations you need to do remotely, they can also prove
to be a performance impediment and will many times lack functionality
needed for a particular application. The Customer Applications Team
(the fine folks that bring you most of the Unity tools you've come to
know and love) will continue working directly with SQL for their
applications for the most part and will ensure the functionality
remains backwards compatible as much as possible. As long as you
stick to using views when reading from the tables and use only stored
procedures when adding/updating/deleting objects, any changes in the
actual table structures in subsequent versions of Unity should be
transparent to you.
Rights you'll need in SQL
To connect to a Unity server from off box, the account you're logged
in as needs to have read and, if you'll be doing updates in your
application, write access to the UnityDB database. By default the SQL
database installs with NT authentication only and this is what we
recommend. Yes, you can setup SQL to also do it's own authentication
which allows you to pass in a login and password via your connection
string, however I don't recommend this as it's not very secure,
Relying on NT to do this for you is a much safer and much cleaner
approach. While it's your system and you can do what you want with
it, just be aware you'll risk severe disapproving looks and raised
eyebrows if I catch you doing it.
The Unity server's SQL is normally configured such that any account
that's a member of the local administrators group (or the built-in
administrators group if it's a domain controller) has full read/write
access to the two Unity databases in SQL: UnityDB and ReportsDB. One
easy way to deal with authentication is to create a security group in
AD/NT that is added to the local administrators group on all Unity
servers you want to connect to. You can then add folks who should be
allowed to run your application(s) into that security group and you're
good to go. Of course you can also add individual users to the local
administrators group or, if you like, take care of adding additional
users or groups that have read and/or write access to UnityDB directly
in the SQL administration interface.
The easiest way to do the direct add mechanism is through the SQL
Enterprise Manager application. Remember that it's OK to install this
application even on systems running MSDE instead of the full SQL 2000
server. For instance on my box I created a security group called
"Jeff's Unity Access Group" and added a few accounts to it. The next
step is to open the Enterprise Manager and drill down to the Security
node on the server in question. Figure x.1 shows what this looks like
Figure x.1
You can, of course, add as many individual accounts or groups as you
like in here. In this case I want to grant full read/write access to
the UnityDB database only. On the properties page for my group's
entry I'd then select the "Database Access" tab and click only the
UnityDB database and assign appropriate roles to the group. For this
example I'd assign "public", "db_datareader" and "db_datawriter" roles
to that group as shown in Figure x.2.
Figure x.2
Please note that you should NOT give any rights found on the "Server
Roles" tab for this! That gives accounts the rights to create
databases and edit properties in SQL Server itself which are
absolutely not necessary for anything we'll be doing with Unity.
This same task can be performed using SQL directly using the GRANT
command. This allows you to get much more specific about which rights
are applied to which tables within the UnityDB database and even get
down to the column level. For instance this command would give my
account read/write/add/delete capabilities on just the CallHandler
table within UnityDB:
GRANT SELECT, INSERT, UPDATE, DELETE
ON CallHandler
TO JLindborg
However, going this route is dangerous since many of the tables
reference other tables and you'd have to be sure you gave all
necessary rights to all tables that were involved in the types of
transactions you wanted to allow. This can be tricky at best and a
never ending pit of pain at worst. I don't recommend this method
unless you really know what you're doing and have a real good reason
for getting so specific.
--
*
ข้อสอบครูชำนาญการพิเศษ *
ข้อสอบครูผู้ช่วย,สอบบรรจุครูผู้ช่วย,แนวข้อสอบครูผู้ช่วย,สอบครูผู้ช่วย,แนวข้อสอบครูผู้ช่วย,ครูผู้ช่วย,ข้อสอบบรรจุครู,ข้อสอบครูชำนาญการพิเศษ
*http://www.oopps.bloggang.com*
*
* ฟิสิกส์ ข้อสอบฟิสิกส์ บทเรียนฟิสิกส์ ฟิสิกส์ออนไลน์
โจทย์ฟิสิกส์ แบบฝึกหัดวิชาฟิสิกส์ โจทย์วิชาฟิสิกส์ โจทย์วิชาฟิสิกส์
http://thaiphysics.blogspot.com
* บทเรียนบทรัก ความรัก บทความความรัก ดูดวงความรัก นิยามความรัก
กลอนรัก เพลงรักhttp://love8love9.blogspot.com
* ความรัก บทความความรัก ดูดวงความรัก นิยามความรัก กลอนรัก
เพลงรักhttp://kongkoymusic.blogspot.com
ไม่มีความคิดเห็น:
แสดงความคิดเห็น