> Sorry, external OS commands are not permitted to be called
> from triggers and
> stored procedures.
> Reasons :
> 1. Security
I would assume that as a designer/developer of triggers/procedures that would operate in this fashion I would take necessary precautions, just as I would when writing a web service or CGI program that invokes commands on my system at the behest of unknown users. Sure, I might mess up. But that's my problem, not sapdb's.
> 2. OS command may block other tasks due the SAPDB threading model
Clearly harder to handle depending on the requirements. In this case however I have no requirement that the external process return or remain attached in any fashion to the database process (although I do need to be able to pass it parameters at fork time). The process could be spawned in any fashion that made sense, including via a designated username/password configured for that procedure by the administrator.
The general business case I need to support is one in which database state changes trigger other business events. Assume supply chain management for example. Let's say I'm a shipping company. My customers want to know when their packages ship. I could write code to poll the database checking shipping status deltas...Not! Or I could put logic in every program in my company that alters shipping status...a lot of duplication of effort. Or I could just put a trigger on the shipment table that says when shipping status changes to 'shipped', invoke this process that emails the sender/receiver a notice. Or better yet, invoke this web service on their system to update them directly ;).
Business workflow event notification tied to the centralized, validated, contrained, transactionally consistent state changes in my business as reflected in the only place that really matters -- my database. That's the business case. BTW, I can do this today in Oracle. Drive my entire business workflow system right out of the database. I'd prefer to do it with SAP DB though :).
ss
