Let me address first the premise you made: "... that there's a specific pattern that every single SaaS tool follows: the sender agent". I would love you to refer me to the source of this statement. In my experience with SaaS, I never heard about such a pattern.
Well, in all honesty, "sender agent" sounds as broad and nebulous as "business component" or "server kernel".
I have my webapp, but it can't talk to the database layer (nor it
shouldn't, of course)
You're not comparing apples to apples here. Webapp is a tier, database is a tier. Webapp tier must talk to database tier. Webapp may have different layers, and a persistence layer within the webapp will talk to the database tier.
... so there is an agent that runs inside my gated network that publishes
to the webapp.
This makes it sound like webapp is a lifeless statue, and an agent is a sculptor who is running around it and throwing chunks of clay on it. Webapp is receiving a request from a client, queries the persistence tier (it could be a cache) and sends back a response. Whatever agents you might have will publish data to a persistence or queuing storage, not the webapp itself.
Read up on layers vs. tiers, it will help you better understand webapps and SaaS models: What's the difference between "Layers" and "Tiers"?
update
Thank you for the clarification, it changes question significantly. What you're doing sounds very reasonable. You're working within constraints of a particular system and you have to satisfy plug-in contract. If the contract states that is has to be HTTP POST then that's what you have to do.
There are dozens of ways on how to do it. Here is just a few:
- an agent(s) pushes event to the server when the event occurs
- in case agents could put too much stress on the server, an agent(s) pushes event to a queue. The queue is then to be drained by dedicated and throttled processes that would read your database and push events to the server
- a scheduled process (a daemon) reads your database at certain intervals and pushes updates to the server