6

I would be really grateful if anybody could help me clarify, where to deploy business logic.

I'm aware of the following possibilities:

  1. Write the main parts of the business logic in Apex

    Apex provides many utility functions and missing functionality could be integrated through external web services. In addition, written code can be deployed as a web service.

    Possible advantages:

    • DRY and KISS, in particular: Code can be easily used in Salesforce and through external services.
    • Less fragmented deployment structure.
    • Focus on Salesforce as primary system.

    Possible disadvantages:

    • High dependency on the Salesforce platform (lock-in).
    • Limitations due to Salesforce quotas (@future method).

  2. Write the business logic in PHP

    Through the Salesforce PHP API, business logic can be deployed on a web server.

    Possible advantages:

    • Less limitations (@future method quota is more restrictive than API request quota)!? Not shure on this point.
    • Less Apex knowledge required.
    • Lower risk for lock-in.

    Possible disadvantages:

    • Solution is less sexy.
    • Maybe duplicate code.
    • Shared business logic (used on several platforms) causes messy information flow.

  3. Write the business logic in JavaScript

    Just to be complete... the JavaScript API could be used, although I think that the business logic should reside on the server side.

Are there more advantages / disadvantages to consider? Are there any best practices?

Edit:

I would like to illustrate my very abstract question with an example.

Imagine you've got an provider for phone tracking and you're able to create new phone numbers through an API and let's assume furthermore there is more effort needed than calling this API (more complex function). In my opinion this is business logic and I would like to refer to this as createTrackableNumber.

The function (or method) createTrackableNumber asks the provider for a new phone number and saves the response to an Salesforce Account.

Moreover you want to provide the createTrackableNumber functionality to the salesperson (usable within Salesforce) and simultaneously through a web based tool to the customer.

In this use case you can't use "point and click". Would you write createTrackableNumber in Apex and expose it as a web service (for example with @RestResource) or would you write it in PHP and use within Salesforce and the web based tool?

Is one possibility maybe more "quota friendly" than the other? Any other considerations to make?

Kind Regards, Florian Kalisch

Improve this question

1 Answer 1

Reset to default
7

I hear you using the term "business logic", yet you're also talking about connectivity API's to talk with external Databases. In SF language, that's normally referred to as "technical architecting". Business logic is what an application does for a user ("After 15 days, create Task to send follow up email to Contact", is an example of business logic). As much of that as possible should be done using Salesforce's native "point and click" capabilities.

As a best practice, one only writes code for things that can't be done using Salesforce's native point and click interface. Why? For starters, because of speed and more importantly for backward compatibility with new releases. API's can change. Point and click features will rarely be broken with new releases.

If you do need to code something, you're far better off to use APEX than to use PHP or JavaScript. Apex is the "native" coding language of the platform and is versioned with new releases of SF. When a new release of SF comes out (3x/year), code written in previous releases is protected and will run under that version until such time as Salesforce announces a particular feature of Apex will no longer be supported and is being superceded by something else. At that point, you'll need to review and update your code.

If you write your code in PHP or Javascript, you won't have anything near this level protected versioning of your code as you will with APEX with new releases of Salesforce. Further, Salesforce isn't at all designed to run PHP from it's servers (yes, it supports it, but that doesn't mean it's suited to it) so you lose numerous features inherent to SF if that's the direction you go. Apex is much more secure than JavaScript or PHP with it's classes that support sharing and you have the advantage in that it allow you to extend standard classes or create custom classes built up from abstracted classes.

Bottom line, best practice would be to use to use what's native to the platform.

Improve this answer
5
  • Yes, "Clicks not Code." If you can implement declaratively, do so. If you can implement natively, do so.
    – Adrian Larson ♦
    May 5, 2015 at 16:39
  • Thank you crmprogdev. I've edited my question to clarify the problem.
    – Florian Kalisch
    May 5, 2015 at 17:22
  • 2
    My response above would still be the same. I would stick to what's native to Salesforce. I would likely use the REST API along with Apex per your example as opposed to PHP. Web services are still going to consume API requests regardless of what language they're written in. Again, this is still technical architecting a solution, not business logic in SF platform terminology
    – crmprogdev
    May 5, 2015 at 17:55
  • @FlorianKalisch, I wanted to point you to a Doc that you may find helpful to you: Integration Patterns and Practices.
    – crmprogdev
    May 9, 2015 at 14:45
  • Thank you @crmprogdev - i've stumbled upon it in the past, but didn't read it in detail. I'll do so in the next days.
    – Florian Kalisch
    May 11, 2015 at 8:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .