This is a common mistake when designing integration. Your requirement is to "sent after the invoice is posted", but your code doesn't do it. Until the transaction is committed, the invoice isn't really posted.
Sending from a transaction is dangerous; not only you must always think about rollbacks, but a problem with the web service can also slow down your ERP system (when the call is slow and prevents the transaction from committing and locks from releasing) or even block the business (invoices can't be posted if the call throws errors).
Therefore calling the web service from a transaction isn't a good idea.
In some cases, you can simply call it after the transaction. It solves all the problems above, but it doesn't guarantee that the message will get send (an error can occur). If you want a more robust solution, use a table to store information about what should be send. Write into it in a transaction; if a rollback occurs, the record will be removed. After committing, take the record and call the web service based on it. It may be done in a batch, but it could also be triggered from code of invoice posting or utilize system code running on transaction commit. This will also allow you to resend the message later if something fails.
By the way, consider using business events. Microsoft already handled these things for you there, therefore you don't have to design a similar thing on your own. You may have a Power Automate flow (or so) getting notified that an invoice was posted, it'll fetch details (e.g. through a virtual entity and the Dataverse connector), compose JSON and send the message.
Moved from Integration, Dataverse, and general topics forum to Finance | Project Operations, Human Resources, AX, GP, SL forum.
