The Remedy data structure is very complex. All tables and columns are flexfields. However, Remedy provides views to report against. If you use the odbc driver that they provide, then security is automatic and dates are handled. If you go straight agianst their views with sql-net, then no security and dates have to be handled by you. If you go to the bo web site and download the rdt documentation, it is fully described there. Although the universe provided in the RDT for remedy is not needed. All you have to do is insert the remedy view into a universe.
You can not build a universe against the remedy tables. The table names and column names are all cryptic.
I have built several universes against Remedy databases. Since the tables are created per user forms, the database structure will be unique to each deployment.
They biggest issue we had was converting dates from Epoch time to Date/Time fields.
We use another call center software package and I had to convert all my Epoch 1/1/1970 time to Eastern Dayalight time ( EST sample )… where “sttime” is the database field.
Ours was much more complex. We had to shift it from GMT to the local time zone of the person who opened the ticket. Then we had to adjust it for daylight savings time. It was pretty intense, but it worked great.
I am working on developing remedy universe using business object to produce Change Request and Service Request(Incident Management) Reports
About the date part, I have to work on that to convert date and Time format. We are trying to put all the date format and measure in seperate database using informatica. If I come across any problem, I will let you guys know.
Did you had chance to work on the Audit Trail field on Remedy Application? When we pull the information the datetime value along with the various status changes are displayed as numbers and since they are not separate columns I cannot convert them to meaningful date value as we see from the Remedy Application when we click on Audit trail where it displays the proper datetime.
I’m working on a similar requirement and was wondering if you can share some points (hope you remember since I’m digging up this thread where you have replied sometime in 2004 ) about the work that you did. We are looking at a Global Userbase and as you mentioned in couple of threads for Remedy the Daylight Savings Time is the most time consuming thing. Did you have some kind of table to have the GMT Times From and To and the Offset for other timezones like people on EST or European timezones or PST etc. I saw from another thread that you went with the DB Driver instead of the Remedy supplied driver which is what we are also looking at. I would also be interested in the approach that you used to finding the user in the timezone that they are in. Did you have a separate User tables maintained to have the TimeZones that they are in?
We created a table which included every telephone area code in the US in one column. The second column list the difference between that area code, and GMT in hours, during Standard time. The third column was the same as the second, but was for Daylight Saving time. We then joined this table to the Employee table so, for each ticket, we could show the dates in the time local to the employee.
Thanks a lot Michael for the quick response. When a user runs a report how do you decide on which column to use (I mean 2nd or 3rd column) to calculate the localtime from the GMT time stored in Remedy System. Do you have some kind of table mapping which holds the GMT Time and if that is Standard time or Daylight Savings time. Please let me know if I’m unclear. Thanks again!
Our DBA wrote a custom Oracle function that would evaluate a date, and return 0 if it was in Standard time, or 1 if it was in Daylight Saving time. We used a CASE statement to decide which column to use, depending on the results of that function.