Apex Code Development You need to sign in to do that
Don't have an account?
kzmp Home page components SF Ajax. Would SF certify this in a package app.
Hi
This is more like two questions in one post.
We have a custom home page component on which we would like to use some AJAX to access external system (call an external web service) and Ajax to interacti with the SF database. And the javascript on that page must execute from the same domain as SF pages.
After a lot of struggling and trial and error. we figured out the following way:
1. Download the Connection.js API from SalesForce and upload it as a static resource.
2. Create a custom html home page component. Include the Connection.js <script type="text/javascript" src="/resource/QAS_NA_TEST__Connection"> write your html and javascript logic there and save it.
So far soo good the only problem is how would the Connection.js salesforce API get its session. After a lot of trial and error we decided to:
3. Create a custom links home page component. The custom link inside is is an "execute javascript" link and it has the following component:
window.sessionIdTest = '{!GETSESSIONID()}';
4. Add an onload javascript event handler in the home page html component in step 1 above with the following body:
var link = $("a:contains('Test link')"); link.attr('onclick',link.attr('href').replace('javascript:','').replace('%28','(').replace('%29',')')); link.trigger('click'); sforce.connection.sessionId = window.sessionIdTest;
The idea is that when the home page loads our html home page component finds the custom link and clicks it. The custom link in turn sets the SF session to a global variable then the Home page component picks up that variable and initializes SF Ajax.
In that way we can call external Web services from our custom html home page component and we can access the SF database which is what we would like to achieve.
Finally the questions:
1.Would anybody suggest anything simpler to do this?
2. Would SalesForce certify this if it is going to be a part of a managed package sold to thid party customers?
Please note that making a VF page and adding that in an iframe to the custom html component is not a solution for us because it is absolutely essential for us that our javascript executes in the same domain as SF.
Thanks,
Kzmp
What you've done is effectively introduce Cross Site Scripting (XSS) in to your application to get around the browser security model.
The browser does not allow data and content from alternate domains to interact. This is a Good Thing. (it would be pretty awful if any tab you had open in your browser could read your Salesforce.com data or your GMail.)
It sounds like you want to link up Salesforce.com with a web service(s) hosted on a different domain. If this is the case, you should use the Salesforce.com API.
You can send an API SessionId {!API.SessionID} to the external web-service. That web service can then call back to the SOAP end point for that user's Salesforce.com org with an API session ID.
Check out the technical library for info and code samples for performing integration with Salesforce.com.
http://wiki.developerforce.com/index.php/Integration
Hi Brendan,
Thank you for responding to this.
What you have explained makes sense but we need for our solution to work in a more interactive way.
We want to achive the following:
1. User opens the account page for editing and fills in an email address.
2. The user moves away from the email address box and as soon as he/she does that we take the email call our webservice which validates the email and returns back some additional information like the name of the person to whom this email belongs to.
3. We take that information and insert it in the First Name, Last name fields in the accounts page.
All of the above is the calling webservices part and it is clear that we need to be able to run javascript in the same domain as SF.
The SF ajax piece we need to be able to fetch from SF various settings that the user can change for our software.
The other reason for SF ajax is that we also want to provide a link sitting next to the email address which is visible to Edit mode and in Detail mode. When the user clicks on the link in Edit mode we do 1, 2 and 3 above, when the user clicks it in Detail mode we save the data to SF and we refresh the current page.
Regards,
Kzmp
If you are trying to change the look and behavior of standard objects (like Account) a think a VisualForce page is the way to go. You shouldn't attempt to include script within the context of *.salesforce.com.
There's currently a few ways to safely perform cross domain messaging.
You can use Cross Origin Resource Sharing (CORS) to accomplish this (your script would be served from Force.com and make calls to yourdomain.com)
CORS is only supported in FF 3.5+, Safari 4+, and IE8+ (Microsoft implements it slightly differently)
There's also HTML5 postmessage.
https://developer.mozilla.org/en/DOM/window.postMessage
If I'm understanding your use case correctly, the code would work like this:
user opens Account page written in VF using standard controller.
VF page includes your script as part of the page or a static resource.
User types in Email Address field
Script makes a cross origin call to yourdomain.com
Script reads response and populates firstname/lastname fields
Hi Brendan,
Thank you for your answer. I find it really helpful. I am going to research all the possibilities that you have listed.
I have two problems with the solution that you are proposing:
1. Because our application will be offered on the AppExchange to third party users making the users have a custom Account page is not an option for us. It will just make it difficult for adoption.
2. In terms of corss domain scripting I think, simlarily to the above that requiring only the latest version of a limited number of browsers will make the application difficult for adoption.
You did understand the use case correctly.
From techinal point of view the difficult pieces are:
1. How to hook up the event on the email field.
2. How to initialize and use SF Ajax to ready the settings which are stored in an sObject of the app
3. How to call an external webservice in a different domain. Actually I am not sure that we have a problem with number 3.
Thanks,
Kzmp
Hooking up the event to the email field is the most difficult. To dynamically update a standard account page, you need to be able to write to the <instance>.salesforce.com DOM. For security reasons, third party code is generally prohibited from running within the context of a .salesforce.com domain.
It also has very practical ramifications for an AppExchange developer. If your code hooked events for the Email field on the standard Account page, nothing would prevent another AppExchange app from doing the same thing. In which case, your application may break, or the apps could break each other and make the Account detail page unusable for the customer. With Force.com, your application gets its own reserved namespace, preventing other applications from interfering with your app, and preventing usability issues for the core Salesforce.com product.
Hi Brendan,
Thanks a lot for your help with this.
The reasons behind the limitations have become clearer to me.
I still need to deliver this functionality and I understand that the solution is a little hacky but what can I do if there is no other way.
Thanks again,
Kzmp