My company hired an agency to create an MQL salesforce object. Its constructed from an Apex class with various triggers.
We no longer have a need for it, and as the standing saleforce admin, there is none at the company who knows Apex. I'm taking classes to learn it, but wanted to check in and see how I can deprecate the object from salesforce by archiving/deleting (or even just commenting out the code) to push the update to production.
Does anyone have insight into how to go about doing this? All of the courses I've taken are basic understanding of Apex and how to write small triggers, classes and queries. The agency who built the class left 0 documentation on its code.
You can't write code in production so whatever you'll try to do - will have to be done in sandbox, tested and then deployed.
There's a way to do a "destructive deployment" and really delete it but you'll need programming tools (VSCode, Eclipse IDE or Ant + Migration Tool). It's bit advanced topic, I'd suggest you hire a dev ;) or try to just comment them out.
In sandbox you can comment out the body (bodies?) of triggers and classes. You shouldn't kill whole file, leave some empty skeletons like
public with sharing class MqlGenerator{
/* kill everything
*/
}
trigger MqlTrigger on MQL__c (after insert){
/* kill everything
*/
}
Of course if there's trigger on Account and it does 10 things, only 2 of them relate to MQL then don't comment everything out ;) It'll be bit of trial and error for you, depends how clean the code is.
You will have to touch triggers, normal classes and likely unit tests too because if they did decent job - there will be tests that verify these triggers do something and now these tests will start to fail.
Add the files to changeset as you go (you do changesets, right? Doesn't sound like you deploy with Git+SFDX for example). From time to time run Apex Classes -> Compile all classes and run unit tests. Some manual testing wouldn't hurt too. If you are unsure what's left you can click on MQL's fields, there's "Where is this used?" button. Or even try clicking delete & repeating until it succeeds ;)
After you deploy this changeset...
If the MQL__c has no triggers (for example it is created in Account updates but itself doesn't have triggers), you might actually be able to delete the object. If there are related triggers, workflows etc SF will stop you. The only way to really delete it would be to run this destructive deploy. It's possible without installing anything, use the link I included and for example workbench would let you make a deployment. But it's bit "pro", if you're unsure start with commenting stuff out and maybe leave the empty skeleton until you're more comfortable. You can always hide the object's Tab, remove right to Read the object and it'll disappear from listviews, reports... it'll be an eyesore only for sysadmins.
If object has to stay around but the data storage is significant you could try truncating the object. If it gives you trouble - Data Loader, export all records (just IDs), then delete. Maybe even with hard delete option so you skip recycle bin.
Related
I want to remove entire tables from Salesforce data that I am no longer using. I also want to prevent Salesforce from writing to these tables moving forward. Where do I start?
If it's your own custom tables you should be able to delete them. Hit delete action next to the table name in object manager and see what explodes?
The rule of thumb is "if you can create it straight in production without running a deployment process - you should be able to delete it". So if by "prevent Salesforce from writing to these" you mean flows, workflows, process builder... - they'll stop your delete, you'll have to get rid of them first before deleting the table itself - but should be relatively easy if repetitive.
It gets more interesting if you have code (triggers, classes, aura/lwc). You'll need to delete them using a special deployment command, changesets are useless. You can try to craft your own so-called destructiveChanges.xml (it'll be documented in metadata API guide) and try to deploy it even without any developer tools (for example with workbench.developerforce.com) but might be better idea to poke developer to do it. Identify dependencies and edit the code / delete classes as needed.
If it's custom tables but not your own (coming from managed package) - maybe packag has some config options, worst case uninstall it?
Whenever I have to run code on the database, change posts, or terms or what have you, I am running it on a custom page template.
Since this has been working for me up to know, I didn’t think about it much. But I need to delete a ton of terms now from a custom taxonomy and I can’t do it on the test page very effectively. Meaning I get 504 gateway errors all the time, because the code takes too long to run, and deletes only a part of the terms.
So I am wondering, if I need to run custom code to change a lot of data, what is the most efficient method to use?
Many people use a plugin named Code Snippets for this. Otherwise it's often more efficient to use direct SQL Queries using phpMyAdmin for example.
I work on Labware LIMS, which has both configuration, and customization via its own programming language and internal code editor, and stores this customization code in database records. (Note, not the source code of the actual application itself, just the customization code a.k.a. LIMS Basic.) Almost everything in LIMS is stored in the database.
We want to investigate the possibility of using source control to protect this code but we don't know much more than the theory of using something like Git. (I have worked as a junior QA and used git but not as a dev and my knowledge is limited!)
Of particular use would be the merging tools, as currently we have to manually merge code in a text editor, if we even notice there is a conflict (checking content between dev and live is time consuming and involves using multiple tools, some of which are 3rd party tools we have developed ourselves, which are hit and miss. I personally find it easiest to cut and paste into a text file and then use Beyond Compare.
There is no notification that the code is different when moving it from dev to live (no deployment as such, you just import an xml file) so we often have things going live that someone was working on unbeknownst to each other. I.e. dev 1 is working on the code in object 1, dev 2 gets a ticket to make a change to object 1, does so and puts their change Live, whatever dev 1 was doing is now also Live in whatever state it was in. (Because we don't always have time to thoroughly check what state each object is in between up to 3 different databases.)
Is it possible to use source control just on the code within the database, but not necessarily the database itself? (We have backups and such for that but its easy for some aspects of the system to get overwritten by multiple devs working on overlapping areas at the same time.)
If anyone reading this has any specific knowledge of LW LIMS, we are referring to the Subroutines mostly, we have versioned Analyses which stands in for source control for the moment and is somewhat effective but no way to control who is doing what on the subroutines other than a comment log at the top. I have tried to find any information on how other teams source control their code in LIMS but to no avail.
The structure of one of these tables can range from as simple as the code just existing in one field as a straight text dump with a few other fields such as changed_on, changed_by and name (Subroutines), or more complex with code relating to one record being sprinkled around in multiple rows on another table entirely (Analyses) but even if it could just deal with the simple scenario to start with that would be great!
TL;DR: Could the contents of the Code field in a database record be treated like a regular code object in other dev environments somehow and source controlled using Git? (And is anyone willing to explain it simply for me to follow?)
As you need to version control table fields of subroutine, but LW LIMS doesn’t have the IDE for version control (such as git, svn etc). So the direct answer is no.
If you really want to do version control for the codes in database, you can create a git repository and only put the codes in git repository. when a file has updated, you can commit & push the changes. And it’s easy to compare the difference between versions.
More detail about git, you can refer git book.
LabWare LIMS has a number of options for version control. You COULD version the Subroutine table by adding a SUBROUTINE.VERSION field to the table, this works the same way as other versioned tables in LabWare where it asks you if you would like to create a new version of the object before saving. There are a few customers I work with that have done this.
Alternatively, (and possibly our more recommended method prior to LEM) there is the Snapshot capability where the system automatically takes a "snapshot" of objects as they are saved - when viewing these you have the ability to view them side by side in a comparison dialogue - it will show < or > for lines which are different.
Another approach is, if you have auditing turned on you are able to view the audit history for changes to specific objects - this includes subroutines.
One other approach is to use configuration packages - this has the ability to record version AND build numbers. Though individual subroutines is probably a bit too granular for it's intended design.
Lastly, since this question was originally posted we have developed a product called LabWare Environment Manager (LEM) which has some good change control functionality built-in.
For more information on the suggestions above, please have a look at the LabWare Technical manual for the version you are on. We also have a mailing list for questions like this to be posted. You might find an answer there. If you have access to our Support webpage you're able to search previous questions that have been asked. I'd also suggest that you get in touch with your Account Manager at LabWare who can help you answer some of your questions.
HTH
I am unsure if this is a bug, by design (though I can't see the benefit), or if I am just being dimwitted.
Using Google App Engine development server, v1.9.8, I can only add a datastore entity if another of the same kind already exists. Otherwise the drop-down physically does not show the entity kind.
Further, even on an entity kind that does exist, I can only change attributes (or create them if it's new) if that attribute is not null on at least one of the other existing entities of that kind.
This is annoying, since in order to test things I have to first do:
entityKind(every=Possible, attribute=Set, to=Something, even=If,
i=Dont, yet=Need).put()
Refresh, and then remember to delete this line before refreshing again to avoid duplicating the entry in datastore.
Note though, that if I happen to be testing with only entities that do not use every attribute, I have to keep this dummy one just in case I want the others later.
I must, surely, be missing something here? I can't believe there isn't a way to just create datastore entities without hacking around it like this?
You are talking about creating entities manually using a Dev server. Over the past 4 years of using GAE I wished once or twice that this would be possible, but I never needed this feature. You create entities in your code, and you debug your code if something does not work.
You can (and should) write unit tests to test your code. A proper unit test creates an entity, saves it, reads it, verifies that all the properties are correct, deletes it, verifies that it was deleted. There is no code to cut and paste (or comment/uncomment), and there are no test entities left after testing is completed.
Your mistake is in thinking of the web console as a part of your workflow. It is absolutely not, and not intended to be. It is a vaguely hacked-together tool that allows you to do some basic operations on your data, and nothing else.
Interact with the datastore via code, and leave the web console for simple verifications.
We need to rename about 15 custom objects in a force.com.
In Java, this would be a right click and about 20 minutes work, but given the number of soql queries, classes, pages, profiles etc that use these object, we're looking at a week, two weeks... or more.
So, ideally, we're looking for a refactoring tool which will help us rename this objects and resolve any interdependencies.
Force.com IDE naturally, doesn't support this. Any ideas/tools/approaches?
We did that with two objects and it was a royal pain, I can image 15 poses quite a challenge. As you noticed by now salesforce constructs are highly interdependent with cross, even circular references being legit. THis on the other hand makes tear-down and core modification very difficult and virtually impossible to automate.
What you can do is following:
Use sandbox for modifications, do an inventory of all constructs using
affected objects. You can use Ctrl-H
to search the entire workspace in IDE
On sandbox, clone those 15 objects into their respective future names,
they'll be empty but who cares on
sandbox.
Now that you have objects in place, rename all mentions in all constructs
from #1 to use new objects
Just to make sure try to delete old objects
from sandbox, this will serve as a
sanity check that you didn't miss any
dependency.
Off work hours delete the entire inventory of #1 from production server, leaving just bare objects with their data
Now that the dependencies are gone, rename all 15 objects
In one session deploy the entire modified inventory from sandbox to
production, since the payload now uses
new object names the tests should
pass.
I dont think it should take you more than a day for all this.