User Actions vs Web Services

User Actions vs Web Services

Out of curiosity, What are the pro's and con's of using a outsystems "web services" over outsystems "User Actions" and vice visa?
This would be interesting to know because a public User Action can be consumed by an application much like a web service can be consumed by an application, except a web service can be consumed by any application. Where as a user action can only be consumed by outsystems eSpace applications.

When using an user action, outsystem can detect changes made to the user action, where as using a web service outsystem would not detect any changes made to the web service. (ie such detection in change to warn the developer eSpace XYZ is out of date)

What about performance? bandwidth consumption? are they both the same? (assuming that everything is running on the same server).

what really happens behind the scenes?
when an eSpace is referenced, does outsystem turn the user action into a web service? or what really happens behind the scenes?
Hi Robert,

This is a great question!

Let me give you me thoughts.

Using Actions vs WebServices is completely different.
With actions you get a hard link in the code, this is nothing more than adding a reference dll in compilation time, hence the Platform can warn you when something is outdated. This doesn't serve much a SOA model, because you only get re-usability within the OutSystems Platform, but you get other benefits from it being the first the transaction context. Referenced public actions executed in the flows use the same transaction as the rest of the flow and this is out-of-box. As up to performance there's no extra payload for calling these actions.

With webreferences you get a fully SOA model but with some drawbacks. You don't have the transaction out-of-box you'll need to program the transaction yourself and this can be very tricky in some situations.
Consider the following example:

Action2 and Action4 are local actions of the eSpace while Action3 is a webreference action. All of them perform changes in the database. Now imagine that everything runs ok up to Action4, where an exception occurs and now you have to decide to rollback or not to rollback. Unfortunately since Action3 is a webreference action and runs in a different transaction its changes are already committed.
In terms of performance it's a fact that webreference actions run in a separate http call with soap. This may have impact if you have many sequential calls to the same action otherwise I think it should not be a problem.

Hope this information helps you.

Also regarding performance and what happens behind-the-scenes...

When an User Action is called, the action code is called directly and is run in the context of the caller eSpace. There's no need to serialize (convert) your data and therefore you'll have a near-zero overhead: it's just as performant as calling an User Action of the same eSpace.

When a WebMethod is called, a new connection has to be opened to the target server, even if both eSpaces are in the same server. This means that your application server will likely have to assign a new thread to process the new request. Both the request data and response will have to be serialized (converted) into the XML dialects used for Web Services, passed through the networking stack of the operating system and then back again. The overhead will therefore be much higher as you'll be consuming more resources everywhere. Convenience for the programmer will also be smaller due to the reasons that André already stated.

In short:
  • for your everyday needs, use User Actions
  • should you need to expose methods to external services, use Web Services
@ André  Thanks for the great response!

"With actions you get a hard link in the code, this is nothing more than adding a reference dll in compilation time, hence the Platform can warn you when something is outdated"

That explains it! So it not actually a web service!  

@Miguel thanks for elaborating on performance,  Everything makes sense perfect sense now Thanks alot!