function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Vinny12Vinny12 

Webservice callouts? @future methods?

Hello,

 

What does this webservice callout means? Where and why do we use it?

 

( I know that webservice is a form of communication b/n the systems)

 

@future methods:

 

What does resources available means?( resources here mean memory,database resources and all) but i didnt get what exactly it meant.  why do we use this annotation?  what is running asynchronously in this context? 

 

Can someone explain a general idea what exactly happens with this external systems,webservice callouts, invoking the future methods from trigger and all and why do we use it. am not able to get a clear idea

 

 

 

Thanks 

 

 

 

 

Best Answer chosen by Admin (Salesforce Developers) 
sfdcfoxsfdcfox

A callout lets salesforce.com access external data. This reduces the need to have an integration server acting as a synchronizing bridge between salesforce.com and that external data. You can use this to get the weather in Timbuktu, the current stock market value for a ticker symbol, credit ratings, process merchant account payments. Anything you can think of, there is probably a service that can do that.

 

Future methods run asynchronously. This means that the currently executing code continues without pause, and the future method is delayed until some point in the future by being placed into a queue. The asynchronous code will be that which is contained in the future method.

 

Consider synchronous vs asynchronous:

 

@future
public static void futuredebug(object x) {
  system.debug(x);
}

public static void currentdebug(object x) {
  system.debug(x);
}

// synchronous example:
@istest
public static void testsync() {
  test.starttest();
  currentdebug(1);
  currentdebug(2);
  test.stoptest();
  // OUTPUT is 1, 2
}

@isTest
public static void testasync() {
  test.starttest();
  futuredebug(1);
  currentdebug(2);
  test.stoptest();
  // OUTPUT is 2, 1
}

In this case, futuredebug is delayed until the end of the current transaction (simulated by test.stoptest()). In a non-test environment, futuredebug() would generate a separate debug log that started some point after the transaction that called it completed.

 

Waiting until resources are available means just that: the calls are placed into a queue, and processed in FIFO order. Normally this queue is short, but if many calls are made in a short time, they could build up and won't be processed immediately. If the queue is empty and the call is short, it is called immediately as the current transaction ends and is basically "tacked on" to the end of the transaction. The effect is that the user will see the new data immediately. Otherwise, the user will have to visit the record later to see the results of any future method.

 

In the example above, the code contained in futuredebug() was called at a later point in time, asynchronously from the main code.

 

Salesforce.com requires that no row-level locks are present on any records involved in a transaction before performing a callout. This is important for several reasons: UI responsiveness, integration responsiveness, and multi-tenancy friendliness.

 

The first requirement is borne out of the need for users to have fast, responsive UIs. If a callout called a synchronous web service, pressing the save button could result in a "white screen" for up to two minutes, causing the users to complain about how slow the app is.

 

The second requirement is the need to have integrations perform as quickly as possible. Long web service calls would lock out integrations randomly for no apparent reason, so they would have to retry their actions, causing wasted bandwidth, processing time, and necessarily making coding integrations more complex.

 

Finally, multi-tenancy refers to the ability to have many uses on a single application at once. In order to have this work well, all users have to be able to modify records in rapid succession. This would be impossible if records were locked all of the time because of long row-level locks. Locks are typically held only for a few seconds at most, allowing more users to use the system at once.

 

So, if you want to update a record in a multi-tenancy friendly method, you have to minimize row-level locking, maximize UI responsiveness, and play well with integrations that also need to read and write to the service.

All Answers

sfdcfoxsfdcfox

A callout lets salesforce.com access external data. This reduces the need to have an integration server acting as a synchronizing bridge between salesforce.com and that external data. You can use this to get the weather in Timbuktu, the current stock market value for a ticker symbol, credit ratings, process merchant account payments. Anything you can think of, there is probably a service that can do that.

 

Future methods run asynchronously. This means that the currently executing code continues without pause, and the future method is delayed until some point in the future by being placed into a queue. The asynchronous code will be that which is contained in the future method.

 

Consider synchronous vs asynchronous:

 

@future
public static void futuredebug(object x) {
  system.debug(x);
}

public static void currentdebug(object x) {
  system.debug(x);
}

// synchronous example:
@istest
public static void testsync() {
  test.starttest();
  currentdebug(1);
  currentdebug(2);
  test.stoptest();
  // OUTPUT is 1, 2
}

@isTest
public static void testasync() {
  test.starttest();
  futuredebug(1);
  currentdebug(2);
  test.stoptest();
  // OUTPUT is 2, 1
}

In this case, futuredebug is delayed until the end of the current transaction (simulated by test.stoptest()). In a non-test environment, futuredebug() would generate a separate debug log that started some point after the transaction that called it completed.

 

Waiting until resources are available means just that: the calls are placed into a queue, and processed in FIFO order. Normally this queue is short, but if many calls are made in a short time, they could build up and won't be processed immediately. If the queue is empty and the call is short, it is called immediately as the current transaction ends and is basically "tacked on" to the end of the transaction. The effect is that the user will see the new data immediately. Otherwise, the user will have to visit the record later to see the results of any future method.

 

In the example above, the code contained in futuredebug() was called at a later point in time, asynchronously from the main code.

 

Salesforce.com requires that no row-level locks are present on any records involved in a transaction before performing a callout. This is important for several reasons: UI responsiveness, integration responsiveness, and multi-tenancy friendliness.

 

The first requirement is borne out of the need for users to have fast, responsive UIs. If a callout called a synchronous web service, pressing the save button could result in a "white screen" for up to two minutes, causing the users to complain about how slow the app is.

 

The second requirement is the need to have integrations perform as quickly as possible. Long web service calls would lock out integrations randomly for no apparent reason, so they would have to retry their actions, causing wasted bandwidth, processing time, and necessarily making coding integrations more complex.

 

Finally, multi-tenancy refers to the ability to have many uses on a single application at once. In order to have this work well, all users have to be able to modify records in rapid succession. This would be impossible if records were locked all of the time because of long row-level locks. Locks are typically held only for a few seconds at most, allowing more users to use the system at once.

 

So, if you want to update a record in a multi-tenancy friendly method, you have to minimize row-level locking, maximize UI responsiveness, and play well with integrations that also need to read and write to the service.

This was selected as the best answer
Vinny12Vinny12

For callouts, do u mean that,

if we need some information from external application ( ex: weather.com or about account payments) we are calling a method in weather.com? and using that information in our application? 

Is that true?

sfdcfoxsfdcfox

That is correct. The two most usual types of callouts are to (1) perform some action in an external system, such as to synchronise data from salesforce.com into the external system, or request some action be performed based on changes in salesforce.com, or (2) bring external system information back into salesforce.com, such as the account's payment history from a separate billing system like QuickBooks online.

 

For example, Linvio is a merchant account processing system. You create a Payment record in salesforce.com, and the response is then stored back into the payment record.

Vinny12Vinny12

Thats a wonderful explanation about future methods and webservice call outs!!

 

Can you pls tell me what exactly wsdl does here?

sfdcfoxsfdcfox

The Web Services Definition Language (WSDL), is used by developers to programmatically create the correct data structures to interact with the service.

 

Without WSDL, each developer would have to write code like this:

String xml = createXml(myObj);
HttpRequest re = createRequest(myObj);
Http binding = new Http();
HttpResponse res = binding.send(re);
Result r = processresponse(myobj,res);
// Do something with R.

Where createXml, createRequest, and processResponse are all user-defined functions that would be dozens or hundreds of lines long. In contrast, after importing a WSDL, you can just do this:

 

SomeServiceClient ssc = new SomeServiceClient();
SomeServiceClientResult result = ssc.someFunction(myObj);

No need to create XML building functions, XML processing functions, Http callout bindings, or any of the rest of the mess associated with calling a service without a WSDL. In short, the WSDL allows WSDL-aware languages to abstract the "boiler-plate" code into a single area that developers don't have to worry about, and focus on just implementing new logic.

Vinny12Vinny12

I Appreciate you.

 

Thats a great explanation.

 

Coming to future methods:

 

As part of theory, am good.

 

Can you give me a real world scenario,

 

For webservice i can give an example like , there is a field "Temperature" in an object  which needs to be updated from external application (Like weather.com). It gets info from that external application and gets updated. ( Correct me if I go wrong) with the help of webservices.

 

Like wise, an example for future method?

 

 

btw, Thanks alot for ur response

sfdcfoxsfdcfox
Future methods are used any time that you can't actually perform the intended action during normal processing of a record. For example, if you need a trigger to evaluate the owner of a record after being assigned with an assignment rule, you cannot do this inside a normal trigger, because assignment rules are executed after triggers. The same is true for webservice callouts, as we discussed previously. A real-world example might be that an order needs to be submitted to a warehouse for fulfillment electronically (using a webservice function), which must take place after the record is fully committed to the database. Another example might be a real-time address-correct service that corrects minor address problems. Yet another example might be that you need to process the results of any other standard activity that occurs after a record is processed, such as task records generated from workflow rules, or synchronized line items from opportunities to quotes.
Vinny12Vinny12

Great!!

 

Thanks 

Neha@SfdcNeha@Sfdc
hi,
I would like to know what these terms exactly mean...method runs Synchronously v/s method runs asynchronously

Thanks