Answer
A useful way to sort this out is to map each integration against how quickly the other system needs the data and how much it matters if a message arrives late or out of order. An order entry lookup that a customer is waiting on needs a synchronous API call with a fast timeout. An inventory sync feeding a reporting dashboard can usually run on a batch schedule or through change data capture off Db2 for i journal receivers without anyone noticing the delay. A high-volume event like a shipment confirmation often fits better on a queue or message broker, so a downstream outage does not block IBM i processing while it waits for an acknowledgment.
Buyers should resist adopting a single integration pattern for every connection just because it is the newest one available. Ask a vendor or partner which pattern they recommend for each specific workflow and why, what happens to a message if the receiving system is down, and how much IBM i staff time the ongoing method will require to monitor and troubleshoot. A pattern that looks elegant in a proposal but nobody on staff can debug at 2 a.m. is not actually the right fit.