enterprise

So I have 2 Oracle installations running great on 4.7.3, and 4.7.4.

So I thought 5.0 would be easy to tackle....totally wrong.

I was on the phone with Oracle late tonight. I'll try and keep this rant short. But, the reason that Oracle will work with 4.7 and not 5.0 is that in 4.7, you have to run your SQL statements manually, and in 5.0 Drupal does this for you. This is a really nice feature. However, that's where the problem comes in:

Currently, the Oracle implementation use sequences and triggers to simulator auto_increment and serial fields. The problem is that you can not create a trigger from PHP, you much run a trigger DDL from Oracle's SQL+ (or if you have Java). For some reason, it's a bug in the oci8 module.

Quickbooks is coming to drupal soon, but I may need help from the community.

I currently have a module that uses SOAP and the RDS (Remote Data Sharing) server from Intuit (a program that runs locally on your machine locally and runs. It acts as a "proxy" b/t you and your quickbooks file, and accepts SOAP requests and pulls the information from quickbooks for you and returns the information in XML format). The module is pretty simple in form currently.

• On a users "My Account" form, an admin user is presented with a drop down of current customers from Quickbooks. The admin then selects what "customers" the registered user can view.

So, we have a few modules that we are running for a new client. We're running drupal on about 60K worth of hardware, not including the Oracle database sitting on it's own nice slice of hardware (about 4 tearbytes of data).

So we get data once a week, millions of rows of data (60 million+). The module that we made for the client has a cron job that runs through and makes some updates (this is along with a Database-side PL\SQL script, and a sprinkle of java. A nice orchestra of apps that work beautifully togather). Well, this takes days to do. Literally days, and we noticed a problem when the "aggregator" failed because it through an error trying to read a certain RSS feed. We were not aware of this for about a week. This cost us and our customer prescious time because since aggregator had filed, the clients custom module never got to run!!! Futher more, I concluded that if I put the custom module first, it would eat up all the cron run time. On top of than, we were seriously "under" utilizing our hardware. This was just totally unaccepatble. Thus comes "Mutli-Threaded Cron" runs.

What this does bascially is fire each modules cron run in it's own "sandbox" if you will. So that each modules cron run has the FULL use of PHP's time out, and does not have to worry about another modules cron run failing. The multi-threaded cron also gives more detailed information about each modules cron run. This will better help site admins control the PHP time out variable (which can now also be set dynamically), and see what modules are taking hte most time to run, the least time, and which ones are currently failing.

I believe this is a BIG improvment over the current cron implementation.
Some items I would like to implement next:

• Emailing the admin if these is a "cron run fail" escalation (say in a 20 min. period, there are 10 failure, email me), etc.
• Being able to set each modules individual PHP execution time variable. (be nice to give search.module more time than aggregator module)
• "Throttle" the cron runs. Meaning, I only want to have 5 cron "threads" running at any given time. So it needs to wait until a few have finished before running more cron threads.

You can review the patch and a detailed discussion of it here: http://drupal.org/node/87528
I'll be discussing more options for mutli-threaded cron runs on my blog: http://www.eb3it.com

Below is a snipped from my blog:

So, I have started an ambitous patch. For those who do not want to read the explination, and just gain knowledge by reading the patch:

Ok, today I am going to start to consolidate all of these diff. db support tasks into my sandbox for a pre-release and discussion setup. Right now, there are about 5 different, and very good, threads about Oracle and MS-SQL support. However, there is still no central place for everyone to consolidate their code and work on the DB's. This needs to happen so no one goes off and re-invents the wheen. So, today I am going to sift through the threads, integrate as much as the code togather as I can, and commit them to my sandbox.

I personally currently have an Oracle installation and a MS-SQL installation working very well.

Note:I welcome others to join the effort and I will provide some tablespace on an Oracle 10g database server to test and implement an Oracle driver for Drupal upon request

I have begun Oracle Support in full gear. After this, I plan to do the same with MS-SQL. I shall start to release my findings here. I am starting with some code from this ( http://drupal.org/node/39260 ) drupal thread. I'm testing against Oracle 10g.

I have installed Drupal 4.7.3, and I am using the database.oracle.inc, and database.oracle.sql very well. I have full funcitnality thus far.

I just wanted to write a short wirte up of my Voxeo Prophecy IVR integration. First, a little bit about Voxeo and the need for it.

Information: http://community.voxeo.com
Prophecy: http://www.voxeo.com/prophecy/

A client had come to our company and they wanted an IVR system (Interactive Voice Response, think of that annoying 'computer' you talk to when you call a bank or business). They just wanted it to simply call their customers and remind them of an appointment. The first quote we got from a vendor was outrageous. We then looked at PhoneTree. They make a very nice system for a very nice price. However, it wasn't flexible enough for our clients needs. So, enter the Voxeo Prophecy server and Drupal. The Prophecy system is a fairly cheap IVR system. It reads CCXML, CallXML, and VXML as 'scripts' to run. Another nice point is that a 2 port system is free. Yes, you can download the system for free and install it on your local server and run it.