server side scripting VS helpdesk package API's.

Say you have a helpdesk package which you use to record details of customer reported problems with their computer hardware/software. This package has an underlying Oracle database(both the helpdesk server and Oracle database lie on a Solaris platform on a SunSparc. You actually perform view, modify, and submit entries using the app user tool;the user tool send any request for view, modify, update to the application's API, which in turn sends the information to the application's server process, which in turn then goes to the Oracle database.(phew!)
If you want to create a web app tool that can view, modify and create entries on this package, is it better to:

1)Use/Create an api program(using the helpdesk package API libraries) that interacts with the application's own API, or

2)Use PHP/ASP to create a web tool that bypasses the helpdesk package altogether and interacts directly with the Oracle database.

I am looking for the best solution in terms of speed of pick up(i.e learning the server-side environment/learning about API's), performance, etc.

If the above is not confusing, can anyone suggest ideas on this?
Thanks in advance.

Don't know the specifics, but it sounds like using the provided API (assuming it is robust enough to provide all the features you need) might be the safer route. Writing a web interface straight to the SQL database requires you re-writing all the business logic that is normally taken care of by the application. I'd expect your development time to be significantly greater.

Also using the API is more likely to shield your web app from future data structure or logic changes.