Posts Tagged ‘apex’
The one thing I have noticed in my time as a Force.com Developer is there is a fundamental difference between someone developing in the Force.com language or someone developing on the Force.com platform. Both have to figure out ways to work within the constraints of Force.com limits. People working with the language see the limits as a constraint but someone who works with the platform understands that constraints breed creativity.
The fundamental difference is are you using best practices?
If you use the following in your Apex Code, whether it be controllers or triggers, then you are really working within the platform and using best practices. What I love about most of these rules as I see it is that they are already spelled out to us in the Apex Documents:
If you have used all of the above or at least some of the above, then you can be considered a developer on the platform. They are all vital to making sure any application you build on the Force.com Platform accounts for any errors that can come up. Something as basic as someone adding a validation rule to the declarative side of Force.com can throw off all of your production code and cause the need for a rollback of data. One of my favorites is the for update used in SOQL queries. Its a great way to make sure that any records you are updating are locked from modification on the declarative side or the API. Many take for granted the possibility for deadlocking resources in the Cloud, but it can happen.
The list above is not the end all be all of what it takes to develop on the platform. These are best practices as I see them and the list is definitely growing.
If you have any question, comments, or anything just leave a comment below or reach out to us at @ModelMetricsInc
Whats wrong with this picture?
There are a few things, but one thing that is obvious which is the basic part of this story:
- This code and any and all Trigger code must be in classes. Triggers run with System Admin privileges and don’t take advantage of any sharing rules or any security restrictions. That is why Apex classes have “with sharing” in their declaration
- The error message should be on the Stage field because its an error driven by the stage field.
- The error message itself should be a System label so if it needs to be translated or changed it can be done without developer intervention.
Other than that its perfectly compilable and runnable code. It addresses whichever use case needs to be addressed and can be unit tested with relative ease.
The BIGGEST issue with this code is that it shouldn’t exist in the first place.
This is what it should be:
The story always is that Surgeons cut, Doctors diagnose, and Coders code. There is always the temptation to cure every and all issues with code. Its what we know how to do well and its what makes us different from others. But none of this means that, as a Force.com Developer, it should be the only weapon in your arsenal.
At Model Metrics we enforce the necessity of Salesforce certifications. For anyone who does Apex code or works with the API we require that they at least have the Force.com Developer certification. If you have either taken this certification or the Dev 401 training you know all they talk about is the declarative portion of Salesforce, not custom.
Something we take for granted is that it needs code. Force.com just as a declarative platform is very powerful and even the most complicated use case can be fulfilled with just clicks.
If you were to come to me and say “I want to lock this parent record with a Checkbox and I want all of the subsequent child records, hundreds of records across eight different sObjects, to be locked as well. A coder will tell you “Sure, we just have a trigger on each of those sObjects, all eight of them, and query against that parent record to see if it is locked. If it is, don’t let them edit the record.” A Force.com Developer SHOULD tell you “Sure, we just have to put validation rules on each child sObject that looks up to that checkbox through the parents lookup field.” The difference in development and support time between the two is staggering. The coder will take a good long time to create eight triggers and subsequent unit tests and make sure they work with any current code existing in the org. The Force.com Developer will do eight validation rules and it will take them an hour. Maybe less.
Now if you were to tell me “I need to do a check across all child records” or “I need to do a callout to an external web service” then OK code it is. Of course keep in mind you can’t do a web service callout from a trigger(yay @future tag!).
There is always the temptation to code first, ask questions later. Force.com Declarative is easily maintainable and doesn’t require any engineering knowledge to work with(but we are more awesome with them!). Apex and the Force.com API allows a Force.com developer to fulfil those use cases that the declarative portion can’t address. Its easy to differentiate between Declarative vs. Custom. Setup a devorg, read the Salesforce books, and take the Developer certification. If you can do that, and you know how to code that’s not IF THEN ELSE, you're a Force.com Developer.
We have had a lot of great interest in Cloud Loader, so the next question is "How do I start using it?" Well, here is a simple 5 Step guide to get going with Cloud Loader to start doing integration for $0.10 an hour (or less with a reserved instance).
Step 1 – Sign Up for EC2
Step 2 – Sign into the EC2 Management Console
The Console is where you can go to create and manage your EC2 Instances. Remember these are virtual servers and the console allows you to give them a static IP (Elastic IP), control the Security Group and stop and start your instances. First off you need to create a new instance of the Cloud Loader AMI.
Step 3 – Create a Cloud Loader Instance
Click on Instances→ Launch Instance→ Community AMIs and search on “Cloud_Loader” to find the Cloud Loader AMI. Click the Select button.
After clicking Select you need to specify some specifics about your instance. You will only need one instance and it can be a “Small” instance which will be fine to run the Cloud Loader.
Next click on “Create” next to the Key Pair Name option, enter a name for your key pair and download the key pair. This will be required to SSH into your Cloud Loader instance.
Next you need to pick a Security Group for the instance. You can use the default one or optionally specify other settings (which ports will be open). EC2 by default has all ports closed except 22 for SSH.
Last Click “Launch” to launch your instance. This will take 3-4 minutes to boot and fully launch.
Step 4 – Connect to your Instance
If you are using a PC you will need to use an SSH client such as PUTTy to log into your instance. Click here for Windows instructions.
If you are using a Mac you can use the native terminal to connect. Click here for detailed instructions on how to set up your certs and bash profile.
Step 5 – Configure your Instance
(Remember this is built on Apex Data Loader, so look here to learn more about it)
• After logging in go to the /usr/local/dataloader directory
• Create an FTP user on the Cloud Loader instance to use for the inbound FTP of data (the .csv file you want to load into Salesforce).
• Edit the config.properties file with your username and password for SFDC
Note: You will need to include your security token at the end of your password if you don’t whitelist the Amazon Elastic IP within Salesforce
• Edit the process-conf.xml file with the data loader processes you want to run
• Edit the automate-dl script to configure the email address you would like to use to send reports to.
• Setup a cron to run the automate-dl script (the way you schedule automated processes in UNIX)
Final Notes
Once you have tested this approach it is likely you will want to modify the script or approach to suit your own business need. With EC2 you can use Cloud Loader as a base AMI and then configure your own AMI based upon it with your own unique additions.
You may also like to utilize EBS (Elastic Block Storage) with Cloud Loader to have persistent storage of your configuration files, incoming integration files or log files. We plan to add this functionality in an upcoming release. If you have any further suggestions for Cloud Loader, please email us at: support@modelmetrics.com
Follow Reid: Twitter.com/ReidCarlberg. A few people on my team contributed to this at different points. Props to Shoby Abdi for getting it all together. Twitter.com/ShobyAbdi.
I recently ran into a challenge regarding a Salesforce-to-Salesforce mashup. We didn’t want to move the data (traditional integration, S2S/org to org sharing), but we also wanted to keep the solution as "clean" as possible — the simplest possible implementation with the fewest possible moving parts. This article is a walk through of how we solved it. I’ve included some lessons learned at the bottom.
Background
* Our goal was to create a mashup without a third party mashup provider.
* Although Apex facilitates callouts to external services, the API specs clearly state that Apex callouts are not designed to call full Salesforce.com API based webservices, so we knew we had to avoid that route.
* We wanted to have avoid creating a large number of dedicated Apex "stubs" on the data provider org.
* In addition to pulling information from the data provider org, we wanted to be update to update a record.
Here are the two screen shots that we ended up with. Note that both are on the calling org. In the first, you can see where a query has resulted in data coming back. In the second, you can see where we’ve updated a field and refreshed the query results. Neat!
Screen 1: The query "Select Id, Name, BillingStreet from Account where BillingState = ‘CA’" results in two records.
Screen 2: Here you can see the results of the first query, as well as my entries in the "update" section. I’m using the data I received from my query to determine which records to update.
Screen 3: And you can see here where "GenePoint" the company I select based on the ID has moved from "345 Shoreline Park" to "123 Reid Updated Blvd." (Class A digs if they ever existed.)
The Basic Process
1. Create a stub in the org that will provide the data. This should be a global webservice class. Save the generated WSDL for this class.
2. Import that WSDL using WSDL2APEX in the org that will consume the data. It will create a matching objects.
3. Create a utility method that handles authentication for you. You won’t be able to use either the partner or enterprise WSDL in your Apex so you’ll need to roll your own. We have a quick & dirty version below.
4. You’ll need a Visualforce page and a Visualforce controller to tie everything together. Those are pretty trivial so I’ve left them out of this post (but they’re in the code, below).
The Code – Data Provider Org
Code is posted in a separate file. Download it!
We started by creating a "DataProviderRequest" Apex Webservice class that executes queries and returns data.
Next was the Data Consumer. Note that this has both a "getSobjectData" and an "updateSobjectData" section.
Code contains working examples of:
* Dynamic SOQL / Dynamic Object Udpates
* Login to one SFDC org from another.
Lessons Learned
* You need to create your own intermediate data type to move content back and forth between the orgs. If you use SObject, you’ll have a schema which includes all of the SObject sub-types. Not very useful (and just too long).
* Performance is reasonably good although not perfect. Caching the session ID rather than logging in every time would improve performance.
* This is a reasonably good alternative to traditional integration methods but IMHO I would generally rather use things like Salesforce to Salesforce if the use case supports it.
* Getting this to production ready will require some tweaking but my over all thought is that it shouldn’t be too hard.
So Dan Galorath has noticed Force.com and started to quantify the savings he believes users can achieve with it. It looks like Marc Benioff sent the results around to all of SFDC. With good reason – Galorath estimates 30-40% lower costs when compared to Java.
Very cool. And consistent with my experience.
In an explanatory article, How Galorath Quantified the Salesforce.com Platform, there are a couple of interesting nuggets hidden all the way at the bottom:
"For applications that are consistent with the built in capabilities of the SalesForce.com Platform, there appears to be about an 80% reduction in the actual development effort. Because of the ability to create with point-and-click operations to support prototyping, the requirements and design effort is reduced with estimates ranging from 10% to 25%."
You read that right: 80% reduction in development effort. Wow.
And, since I’m a nitpicker, I’m going to pick on one thing. Galorath writes:
"APEX does not provide UI services or support external web service calls, the primary focus is to provide data oriented transactional services – more like Stored Procedures in Oracle or SQL Server."
The web services call issue is just incorrect. APEX absolutely supports those. And the UI services section — I think this is splitting hairs. APEX doesn’t, but Visualforce does.
Oh and since I’m really a nitpicker, it’s not "SalesForce.com" with a capital "F". It’s lower case. C’mon people.
Glad to see Force.com getting some good formal attention. Now if we could just get some Z notation animators for it.
Blog
Contact Us