across ALL types of integration technologies
At some point I had plans of precisely doing this, but lost interest.
Initially we were talking about AIS vs BSSV
I don't have time or the interest to delve into BSSV. Besides, my expertise is in .NET and not Java. Based on integration architecture, I suspect that BSSV will only be marginally faster than AIS.
and greater with 3rd party products...?
Most 3rd party products use XML call object. Again, I don't have the time to do this - may be someone can volunteer to do this? Our product does not use XML call object - it is built from scratch. For something like a 1000 line journal entry, the XML request will be pretty large and it has the potential of crashing the XML call object kernel. The sales order scenario you suggested is a better candidate to test.
But not just a single 1000 line journal entry (which isn't common) - instead doing something like 1000 x 5 line Sales Orders.
If/when I get to this, I will let you know. I suspect that our product will still outperform AIS, but not by that much of a margin.
What I liked about AIS was the "briskness" with which it opens forms (assuming they have already been opened). However, there were some annoyances as well - 1) If I created a request with invalid data in the grid, I have pretty much start over (i.e. close the form and reopen it). If I fix the request send the same request over (as you normally would in an integration debugging scenario), it will simply add more data to the grid! I can, of course, send a request to delete/update the bad grid rows, but that is not part of the normal integration workflow. 2) Error Handling: Errors like bad account numbers etc. show up in the response, but I did not see how those errors co-relate to the input (may be I am not looking in the right place?). For e.g. if there are 5 lines and the 4th line has an error, there was nothing in the error to indicate that the 4th line had the error. In the normal E1 form, the field will "red out".