Skip to main content

Salesforce Apex: Replacing and/or Removing Apex Classes

Working with code within the constraints of Salesforce's workflow can be a challenge.  First, you have the restriction on changing anything in production.  Second, you have the requirement for 75% or greater unit test coverage.  Third, you have the fact that certain metadata cannot be pushed to production through a changeset (which means the only way to sync record IDs is by re-deploying the development environment from production).

Fourth - and this is what I'd like to blog about today - you cannot delete classes from production through the Salesforce UI.  The only way to delete a class from production is to download the class (and its associated metadata file) into the Eclipse IDE (which you have previously set up with the Apex add-on), change the "status" flag to "Deleted", then deploy the changed metadata file to production.  And (here's the kicker)...sometimes it doesn't work because...reasons.

So let's start with the workflow of a file deletion.  We'll make the assumption that the class in question is simply no longer needed.  Here is the process:

  1. On the sandbox server, comment out the body of the file and any associated test classes
  2. Create an "outbound changeset" that includes the altered class files
  3. Upload the changeset to production Salesforce
  4. Wait five to ten minutes for the changeset to become available in production
  5. On the production server, check for "inbound changesets" - the one you pushed will probably be available by now (keep trying if it isn't)
  6. Click the "Validate" button and the "Run default tests" option and validate
  7. If there are any errors in any related classes, methods, triggers, etc...you will have to go back to the sandbox and fix them before you can deploy your changes again
  8. Once validation has passed, you can deploy your now commented-out file
  9. In Eclipse, right click on "Apex" at the top of your navigation panel
  10. Hover over the "Force.com" menu item, then select "Refresh from server"
  11. After refreshing, make sure you see the commented-out file. (If you don't see the file at all, you will need to toggle the view in your Force.com -> Project Properties -> Force.com -> Project Contents by clicking "Add/Remove...")
  12. Now find the metadata file for your class and its related test class. They will have the same class name but end with "-meta.xml"
  13. Toggle the "status" on each file to "Deleted" and save
  14. Right-click on the metadata file and from the Force.com menu, select "Save to server"
  15. You will have to select the environment to save to ("production") and then provide your Salesforce credentials for each save
  16. On production, open up the developer console (which allows you to look at your Apex classes, but not change them) and verify that the files are, in fact, deleted
  17. If the files are not deleted, close Eclipse and reopen, then start again from step #9 (above)
That's it!  That's all you have to do to delete an Apex class (basically, a Java class) from a Salesforce production instance.  Easy, right?

Okay, not so much.  But the really irksome thing is that just renaming a class requires all of the above steps.  In other words, if you rename a class in sandbox, you no longer have that class in sandbox but it still exists in production.  So that means that in production, you now have two classes with the same content duplicating the same work, possibly in a very destructive manner.

So to rename a class, you have to create another class with the name you want with the same content as your old class, then do steps 1 through 17 above but include your new classes in your changeset in step #3.  You MUST make sure that your old classes are commented out and your new classes are working in production or it could be catastrophic to your org and you will probably be fired.

Welcome to Salesforce development!

Comments

Popular posts from this blog

jQuery noUIslider Pip Label Customization

Recently, I was tasked with creating a slider element for a user to select their credit rating, of which the user can select from among: 'Poor', 'Fair', 'Good', 'Excellent' and 'Not Sure'.  Several problems presented themselves here: A drop-down box would be better, but that's not what the requirements specified. I already have several numeric sliders on my page and I want them all to match. I selected the jQuery noUi Slider library to create the numeric sliders. noUi Slider does not support string values - only numeric values. The "pips" (slider scale/labels) also does not support string values. Since the solution involved shifting my mindset, I wanted to document it here for future reference and maybe to help someone facing the same requirements. Here's my solution: Since there is really no numeric correlation to credit score (especially considering one of the options is "Not Sure"), I will just u...

Regarding Technology (a departure from WebDev)

I'm departing from WebDev for a minute to blog about technology. I'm as guilty of over-indulging in technology as anyone, especially given that my career demands a technology overload. Today at noon is the solar eclipse and that prompted me to think about the past and the future. I started to think about where the world stands and a song came up on my playlist that seemed perfect for my mood. 27 years ago, Bad Religion wrote a song about the current generation of kids. It would be prophetic if it weren't for the fact that the trend had already begun back then. In any event, it seems now is a good time to look back at the lyrics: 'Cause I'm a twenty-first century digital boy I don't know how to live but I got a lot of toys My daddy's a lazy middle-class intellectual My mommy's on Valium, so ineffectual What child these days does not have multiple devices to play with? Gaming systems, television, computers and tablets are in nearly every home. Kid...

Java...Still Sucking Hard, Compared to Other Languages

I know there are a bunch of Java devotees out there.  I frequently have them evangelizing the language to me as a "strongly-typed" language that is so much better than loosely-typed languages, like PHP.  So here is something that just came up for me and I'd like to ask all those devotees WHY they like the type enforcement. Here's a bit of code to store a random integer as a string in PHP: $myString = rand(5); And now...the Java version: String myString = String . valueOf ( Integer . valueOf ( Math . random () * 10000 )); I get it...you need to keep your phony-baloney job and writing more  code and making it more complicated can help you keep it out of the hands of less "intelligent" programmers. As for myself, I will always prefer a language that lets me write shorter, more eloquent code and get my applications built faster.  But then...maybe I'm just simple.