Apex Code Development You need to sign in to do that
Don't have an account?
JerryH Programmatically Create A New StaticResource?
I've been able to figure out how to programmatically load / read the contents of a StaticResource...
// resource name is "testAccount" in this case
List<StaticResource> lstResource = [select Body from StaticResource where Name like '%Account'];
dom.Document doc = new dom.Document();
doc.load(lstResource.get(0).Body.ToString());
...but so far I haven't been able to figure out how to create a new StaticResource out of whole cloth and save it. The API says it supports all of the standard accessors (create, update, etc.) but so far I haven't been able to get any combinations or permutations to work for me.
So is this possible? And if it is, then what the heck am I doing wrong?
Jerry (Very Much Argh!) H.
The web services documentation states that StaticResource can have DML operations (and indeed, it can). However, Apex Code does not always support DML operations that the web services API supports. The correct method, were it supported, would have been:
You can create Attachments through Apex Code, so I don't see why this is any different, but I'm sure the developers had their reasons.
Ayep -- your snippet is pretty much what I was trying without any success.
Thanks for saving me some time, though. I'm off to see if there's any file I/O support in the API. Betting there isn't. :-)
Jerry (Sigh) H.
Well, "file i/o" wouldn't make sense in the traditional sense (imagine the Force.com platform letting you fopen a file!), but you can certainly move files around with the API. Data types that hold binary data each have a Base64 field that can hold a BLOB (Binary Large OBject). In the API, you encode this data as a Base64 string, and the server knows well enough to translate it back into binary data when it is received. The Apex Data Loader has a CLI/batch mode, so you can script access to Salesforce by using it. By default, the Apex Data Loader will recognize a file path when a CSV field is mapped to a Base64 field, and will attempt to open the file, encode it to base64, and pass the data to Salesforce, just as any other API call. If you script it yourself, you will need to check the documentation for rules on if you need to encode the data or if it will automatically be converted based on the SOAP type attribute. Maybe you could expand a bit on what you're trying to, and we can point you in the right direction?
> Maybe you could expand a bit on what you're trying to, and we can point you in the right direction?
Well, *that's* a sticky wicket. :-D
I'm trying to figure out a way to preserve one additional bit of information on the Salesforce side of my addin application without having to add another custom field to my addin.
The reason I can't add that one extra custom field is because doing so would lock me out of the "push update" features in Salesforce.
So because of the very (very!) stringent limitations and restrictions on what can be included in a "push update" I've been forced to jump through more than a few (rather awkward, from a coding perspective) hoops to be able to deliver additional functionality to our users while avoiding any of the Salesforce "push update" traps and pitfalls.
Suggestions, comments, tips, or other solutions gratefully accepted! :-)
Jerry H.
Sounds reasonable enough. We're always fighting the limits that Salesforce has in place. How much data does this one little bit of information consume? If it were just a setting (per-user?) you might look at Custom Settings. If it's per record, maybe you could just store that data in an attachment or note on each record. Finally, maybe you could just use Document storage to store this additional information. There are ways to store that additional information that are already built-in. I'm not exactly familiar with the "push" limitations (I've never personally encountered them), but there is definitely more than one way to skin that cat.