Profile Id in database

[karenclark_brown]

We are trying to set up our database with a seperate testing environment without having to use an entire seperate server.  It looks like there is a Profile ID setting in the configuration, but there is not detail what this is for or if it can be used for this purpose.  Has anyone used this setting before? Can it be used to seperate the TEST data in the database by setting up applications under the TEST profile ID?       

           we are using uccx 8.5

[Anthony Holloway]

Could you help me understand where you are seeing this Profile ID?  I would like to check it out on my own system.  Thanks.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[karenclark_brown]

page 40 of the databse schema:

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_8_0/user/guide/uccx801dbschema.pdf

Has this info:

　

　

ProfileIDMapping

Database table name:

ProfileIDMapping

The Unified CCX system creates a new record in the ProfileIDMapping table when a new profile is set up in the Unified CCX Administration.

A ProfileIDMapping record shows the mapping of the profile name to its unique identifier.

The ProfileIDMapping table contains the information shown in Table 1-15.

　

　

　

Table 1-15ProfileIDMapping Table Fields Field Name	Description	Storage
profileName	Name of the profile, as set up in the Unified CCX Administration.	nvarchar(50) NOT NULL Primary Key
profileID	Identifier of the profile.	int NOT NULL

I have never used this field and i dont know where it is in uccx, but my hunch is that it may be useful in seperating a test environment from a live ....

[Anthony Holloway]

I vaguely remember this from UCCX 4x when you needed to know th profile name for BARS.

Ok, so I cannot help you out with this particular field in the database, simply because I'm not familiar with it.  However, I might be able to help you with your end goal, or integrating the prodcution environment with the test environment.

So you have two UCCX instances and one third party DB server, correct?  Rereading your original post makes it seem like you might be interested in modifying the UCCX DB itself, but I cannot tell for sure.

Could you explain how you are using the DB in your solution?

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[karenclark_brown]

Yes. sometimes we get so caught up in the detail, that we neglect the possibility of a simpler means to acheive our solution.

what we are trying to get at, is with 1 uccx environment; the ability to seperate the test data from the live data, other then pre and post go live date.  This customer has the need to continually test in their environment due to the changing of teams and data.  They also will have training users makeing test calls and such.

With their 3rd party reporting appliction (clickview), they want to only see live data. and run reports on that.

I've explained that we have a TEST application seperate from the LIVE applications.  and that we TEST AGents , seperate from the LIVE agents and that they can run reports on only the live, but they are looking for a simpler way .....

does this make more sense?

[Anthony Holloway]

Yes, that is perfectly clear.

First let me say that whenever I use to built out a solution and test it to no end prior to putting it into production, I would always make the client aware that when they run their first reports for periods which include the testing phase, the metrics will be skewed.  Therefore, it's always best to purge historical data before going into production, or if you can deploy on the first of a month, for a clean reporting break.

Now in your instance, you are not just talking about testing prior to the system being placed into production, you have ongoing testing on your production environment.

That's a challenging one.

I think the easiest answer is to have a parallel system for testing new features/ways of doing things, however that's probably also the most expensive.

I wouldn't feel comfortable telling you to modify the UCCX database, however, going down the path of prefixing your triggers with special test digits, and your apps, skills, agents, csqs, etc all with "test" seems to be the best solution.  Your third party vendor should be able to exclude any records where these prefixes exist.  I'm not sure why they gave you push back.

In summary, my recommendation would be for a parallel UCCX instance where you lab up new ideas.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.