You can achieve the vision in the drawing. As I see it, you need the following pieces:
- An abstract base class (
WS
) that the other classes will inherit from, or an interface, depending on the exact use of the other classes.
- A scheduled class that executes periodically to check if the server is available, and if so, kick off a batch process.
- A batch class (can be the same as the prior class-- they're just interfaces) that queries pending messages, and attempts to execute them; once completed, they can be marked as such.
- A custom object that holds the queued data, which you can sort by creation date in order to guarantee transaction order.
There's no reason why the system infrastructure couldn't support this design model. It has an added level of robustness, because the normal Outbound Messaging system will discard messages that exceed a certain time limit (24 hours), and does not guarantee message order.
Can you see any problem on my approach?
It is ideally achievable, and probably easier to build than you realize.
Have this approach any governor limitation? It is planned for Unlimited
Batch methods only get to use 10 callouts per transaction, so you'll have to make sure you are setting the scope size appropriately. I'd probably save a "connection check" and simply try to execute the function-- if it fails, you can catch the exception and retry those messages later.
Is out there any better/simpler approach to build a 99.9% reliable integration (SF > WS SOAP) ?
In theory, a polling loop on the other server might be more efficient in the long term, but the salesforce.com infrastructure can easily support this logic for thousands or even tens of thousands of calls per day (or more). The guaranteed transaction order piece is what makes this proposed solution attractive.
Could you suggest any improvement?
The system should work perfectly well. The tricky part might be the actual implementation, but this is a sound design.
Best Answer
This is a rather strange hard limit on the number of parameters a method can have in Apex. It doesn't get in the way normally - a large number of parameters is not a good approach to use - but can get in the way of some automatically generated code.
If your API has many parameters they are probably best grouped into objects in any case. So instead of a flat list of method parameters define and use classes (with class names and field names that relate to the terminology of the domain your are coding for) to group the parameters:
As well as staying within the parameter limit, this will hopefully also make your API easier to understand/use.
There is an example of this approach in Considerations for Using the WebService Keyword.