I have a third party Apex web service I can call without issue from PRM Portal via a third party Flex object. With the same Flex object on a Sites page and authenticating with the same Portal user and Site.login(), the web service call fails with the Sites In Construction redirect. I notice if I change the web service endpoint passed into Flex to my Portal endpoint the call is permitted. I'm confused about web service authorization from Sites vs PRM Portal.
Every 15 mins under Monitoring, I see this message for each Escalation. Is this to be expected? Is this a harmless note just indicating it's still Escalated and no action taken?
User creates record from one of these devices and I want to track this. Is there an existing field on the Activity, Account, and Contact I can use to determine origination? Or can I get something from Apex? Maybe the record type?
Any help is appreciated. It's unfortunate this isn't easy to get at.
I have an urgent issue. The goal is to update the current user's profile via Apex. Since I can't do this as myself, I make an HTTP callout and log into the Web service API as another user. In principle this should work, and my code is below.
The problem is that the sid session cookie is not recognized when I call the myApexPage page and I get a redirect back to the login Url. Are there issues around passing cookie headers using Apex? Is sid not the right cookie name? I've tried setting the cookie domain and path properties but this doesn't help.
Any help is very much appreciated.
Http h = new Http(); HttpRequest req = new HttpRequest(); req.setMethod('GET'); req.setEndpoint('https://na5.salesforce.com/?un=username&pw=123456&loginType='); HttpResponse res = h.send(req); string loc = res.getHeader('Location'); if (loc.indexOf('sid=') > -1) { string sid = loc.substring(loc.indexOf('sid=')+4, loc.indexOf('je=')-1); req = new HttpRequest(); req.setMethod('GET'); req.setEndpoint('https://na5.salesforce.com/apex/myApexPage'); req.setHeader('Cookie','sid='+sid); req.setHeader('Cookie','session_id='+sid); res = h.send(req);
I want to automate Opportunity sharing with Apex and I know I can't create sharing rules programmatically. I'm wondering if I can use manual shares to approximate the behavior of a rule.
I mean, if I add triggers to the creation/deletion of every opportunity, managing a manual share, have I achieved the same result as the rule? Is there anything the rule does that I would be leaving out, like other kinds of recalculations? If it makes a difference, I would be managing the share for a group (role) and not individual users.
Is there any guarantee on when a method marked future will execute?
Let's say I want to invoke a web service asynchronously from Apex using future. The user waits on the page while I poll a field which is updated with the service return value. But if my future block doesn't execute for two minutes this won't work well for me.
I have an urgent issue. The goal is to update the current user's profile via Apex. Since I can't do this as myself, I make an HTTP callout and log into the Web service API as another user. In principle this should work, and my code is below.
The problem is that the sid session cookie is not recognized when I call the myApexPage page and I get a redirect back to the login Url. Are there issues around passing cookie headers using Apex? Is sid not the right cookie name? I've tried setting the cookie domain and path properties but this doesn't help.
Any help is very much appreciated.
Http h = new Http(); HttpRequest req = new HttpRequest(); req.setMethod('GET'); req.setEndpoint('https://na5.salesforce.com/?un=username&pw=123456&loginType='); HttpResponse res = h.send(req); string loc = res.getHeader('Location'); if (loc.indexOf('sid=') > -1) { string sid = loc.substring(loc.indexOf('sid=')+4, loc.indexOf('je=')-1); req = new HttpRequest(); req.setMethod('GET'); req.setEndpoint('https://na5.salesforce.com/apex/myApexPage'); req.setHeader('Cookie','sid='+sid); req.setHeader('Cookie','session_id='+sid); res = h.send(req);
It seems from my reading that Salesforce supports a delegated authentication model where the user types login/passwd into Salesforce and Saleforce passes the info to us for authentication. Unfortunately our Shibboleth system requires that Salesforce bounce the user to our login page and we take the login/passwd from them, then redirect back to Salesforce once successfully logged in. For security we don't want anyone else handling the password. Is our way of doing it possible with Salesforce?
I want to automate Opportunity sharing with Apex and I know I can't create sharing rules programmatically. I'm wondering if I can use manual shares to approximate the behavior of a rule.
I mean, if I add triggers to the creation/deletion of every opportunity, managing a manual share, have I achieved the same result as the rule? Is there anything the rule does that I would be leaving out, like other kinds of recalculations? If it makes a difference, I would be managing the share for a group (role) and not individual users.
I've got an object defined with an "external ID" field (in this case, email address).
We've got code that takes real-world values and upserts them into this object. We don't bother querying for matches first - we just upsert the given values, knowing that the object they will either insert (if new) or update (thus resolving to the correct ID). Either way my SObjects are guaranteed to have a valid ID post-upsert.
However, if I run enough processes in parallel, I'll get an upsert error:
EXCEPTION: Upsert failed. First exception on row 0; first error: DUPLICATE_VALUE, duplicate value found: i__FullAddr__c duplicates value on record with id: a0T700000003bX4
I'll investigate using the Database.upsert() method to retry the upsert on failure; hopefully that will fix the problem.
Am I smoking crack to think that upsert should be an atomic operation? This is empirically not the case - we've clearly got interleaved upserts - but is this a bug or a "feature"?
