+ Start a Discussion
SatgurSatgur 

S-control replacement - Best option

Hi,

As we know, starting next year Salesforce will stop providing option to write/develop new s-controls in the org. This is part of the product roadmap where s-control becomes an obsolete technology moving forward.

 

Does Salesforce have a recommendation on the replacement options of existing s-controls that are working today? As s-controls nears EOL (end of life) stage, even older s-controls will have to be retired and converted into an alternate technology like Visualforce.

 

1) I wanted to check with peers in this forum, if you are aware of any recommended approaches to migrate or replace s-control code.

 

2) One of the pattern that has started emerging (at least this is what I notice with some of our customers where we have lot of non-UI s-controls doing batch kind of processing) - bulk of the processing within s-control, mostly dealing with SOQL & DML operations, has been moved to APEX class and exposed as a Web Service.

 

existing s-controls becomes lightweight and invokes APEX web service for main business logic.

 

In this case, since most of logic has already been shifted out of s-control we can easily get rid of such s-controls by using inline Javascript option and whatever little processing is being done in s-control (showing alerts to user etc), that can be accommodated in inline Java script and hence practically doing away with s-control.

 

So we can see below pattern, as a  phased approach for retiring s-control :

 

A) custom link on page --> invokes s-control --> API calls to server

B) custom link on page --> invokes trimmed down s-control --> calls APEX web service --> Database calls

C) custom link on page --> inline JavaScript code --> calls APEX web service --> database calls

 

Would like to invite comments on above approach (works with non-UI, batch process s-contols) from experienced s-controls developers to validate if solution (C) will work equally fine.  

 

Important --> Remember we continue to use/refer to "connection.js" & "apex.js" in option C (inline javascript) as well. Since this is part of AJAX toolkit, I believe retirement of s-controls from the scene isn't going to impact the way we work with AJAX toolkit in future.

 

3) For bulk data processing s-controls, we can't think of replacing it with Visualforce as APEX governor limits constraints starts applying. In s-controls, we had the flexibility to batch and process records so we can work around these governor limits. For that matter any client application on force.com API doesn't have restriction on governor limits.

 

So question is how do we handle such cases? What can be a possible retirement strategy? VF+FLEX mashup? 

 

Appreciate your comments, suggestions.

 

 

Thanks

Satgur

Best Answer chosen by Admin (Salesforce Developers) 
Doug ACFDoug ACF

Based on the direction SFDC is heading, for our client projects we have moved away from On-Click Javascript and AJAX toolkit altogether in favor of doing everything with Visualforce and Apex.  Even custom buttons which don't cause a new user interface to display we are implementing as a call to a shell Visualforce page that invokes Apex to perform the logic/DML.  Any validation error messages, etc. can be displayed via that page.  Avoiding On-Click Javascript also makes code deployment/version control easier.

 

Any time we have a client request a change to an existing S-Control, we are taking that opportunity to port it to Visualforce/Apex.

 

For bulk sorts of operations, take a look at the ActionPoller capability in Visualforce.

All Answers

mtbclimbermtbclimber

As the warning states in the application, Visualforce supersedes scontrols and you should be moving toward it and not onclick javascript as we're generally moving away from supporting javascript in pages hosted under the salesforce domain so we can leverage the browser security model.

 

If you have moved your logic to apex webservices you can easily migrate to Visualforce with controllers/extension classes that invoke your static methods directly. 

 

One more comment/question about #3

 


Satgur wrote:
...

3) For bulk data processing s-controls, we can't think of replacing it with Visualforce as APEX governor limits constraints starts applying. In s-controls, we had the flexibility to batch and process records so we can work around these governor limits. For that matter any client application on force.com API doesn't have restriction on governor limits.


How do you work around the governor limits in an scontrol? By using the client to batch your processing across (API) requests?  You can do the exact same thing in Visualforce and many have already done this.  In fact, if you call back to your page's controller/extension (Apex) you can process more data in a Visualforce request than you can in an API request, e.g. a Visualforce request can process (DML) 10k rows with one request while the API can only do 200.

 

Message Edited by mtbclimber on 02-25-2009 03:28 PM
Doug ACFDoug ACF

Based on the direction SFDC is heading, for our client projects we have moved away from On-Click Javascript and AJAX toolkit altogether in favor of doing everything with Visualforce and Apex.  Even custom buttons which don't cause a new user interface to display we are implementing as a call to a shell Visualforce page that invokes Apex to perform the logic/DML.  Any validation error messages, etc. can be displayed via that page.  Avoiding On-Click Javascript also makes code deployment/version control easier.

 

Any time we have a client request a change to an existing S-Control, we are taking that opportunity to port it to Visualforce/Apex.

 

For bulk sorts of operations, take a look at the ActionPoller capability in Visualforce.

This was selected as the best answer
SatgurSatgur

Thanks Andrew & Doug for these useful hints.

 

We have always worked around governor limits by batching requests around APIs in s-control.

 

Let me try suggested options in Visualforce (Callbacks, ActionPoller) and will get back to you shortly.

SatgurSatgur

Andrew,

 

We completed some POCs over past few weeks to convert S-control program into pure VF (using action poller as suggested by Doug). I will share some findings from that shortly, but before that I wanted to check with you on following queries -

 

1) Other recommendation from you as quoted below (i.e. callback to controller/extension method). I explored a lot on this but could not see any capability in VF so far to build such callback mechanism. Really appreciate if you can elaborate further on same (or point me to some relevant post on this forum which discusses how to use this.

 

 


mtbclimber wrote:

 

"You can do the exact same thing in Visualforce and many have already done this.  In fact, if you call back to your page's controller/extension (Apex) you can process more data in a Visualforce request than you can in an API request, e.g. a Visualforce request can process (DML) 10k rows with one request while the API can only do 200. "

 


2) Also could you provide details reg. how to process more than 10K rows while doing DML from Visualforce? As per my observation from POC, VF controller works on list/arrays where Apex Governor limits, of 1K elements in the list, applies. Hence in order to process 10K rows of data, I had to first populate 1k records in the list & then perform a DML to push these records to database. Then process 1K record more in next iteration of the loop. So here we process it in batches of 1000, & not 10K.

 

It would be of great help to have your inputs on above queries.

 

Before I publish the findings from POC, just wanted to confirm this with you. Otherwise only possible option is to go with ActionPoller (as pointed by Doug).

 

Thanks

Satgur