0

I'm doing some client work where values selected from certain picklists will need to be sent to an SAP web service. I used WSDL2Apex to auto-generate classes.

The restricted-value fields typically either require a digit or a four-letter code. In the UI though we want this to be friendlier, however Salesforce doesn't really support key-value picklists.

So for a mock example, suppose one field for the web service is called CANDYTYPE, and the options are: CHEW (Chewy candy) STCK (Sticky candy) CNCH (Crunchy candy)

I'd rather have the descriptive names in the UI but I need to send the 4-letter codes to the web service. Ideally my Apex code that packages the data into a web service request should not have to scan for the string "Sticky candy" because maybe my client will decide to rename the picklist value to "Gummy candy" instead.

Ideas that have occurred to me so far:

  • Use a custom setting or custom metadata type to store the mappings, so that at least if a client needs a picklist value edited we only have to edit two things without deploying new Apex code.
  • Compromise by setting the picklist values to "CHEW - Chewy Candy", "STCK - Sticky Candy" etc so that I can just take a substring of the picklist values.
  • Enable translations so that the picklist values can be CHEW, STCK, CNCH but the labels displayed are descriptive. I'm a little wary of this option as it has other consequences that could disrupt work we've already done for the client.

Any other ideas?

Improve this question
2
  • Are you using any middleware in this implementation? (Boomi, CastIron, Jitterbit, etc.)
    – Mark Pond
    Oct 27, 2016 at 16:30
  • No this is a direct callout to a web service that our client does not host or control. They are an authorized distributor of another company's products, and that company's SAP system has a SOAP API that requires certain reports to be fed up to it daily.
    – Charles T
    Oct 27, 2016 at 17:14

1 Answer 1

Reset to default
0

I'd steer away from using translations, as it sounds complicated, and hard-coding the values is certainly less than ideal. Using Custom Metadata is probably the most appropriate means of managing this data, as it can be queried without using SOQL governor limits, is portable between orgs using standard metadata API tools and change sets, etc.

Improve this answer
4
  • Fair enough. I just wish that we had an option to have custom settings/metadata drive the picklist values. Changes to picklist values still end up requiring another edit elsewhere.
    – Charles T
    Oct 27, 2016 at 16:00
  • @CharlesT I agree. A custom Key/Label pair picklist feature would be very useful.
    – sfdcfox
    Oct 27, 2016 at 16:01
  • On a similar note, it would be great if objects could have lookups to custom metadata. I see a lot of objects in client orgs that carry information which should really qualify as metadata, but they're objects because other objects need to lookup to them.
    – Charles T
    Oct 27, 2016 at 18:31
  • Another thought: If Custom Metadata supported Global Picklists this would be the best way to do it. You could simply add the picklist as a metadata field, create a record for each mapping, and then access it from code.
    – Charles T
    Nov 1, 2016 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.