1

I have technical design needs to be finalized. I want to get some expert opinion about which approach would be better. Please provide me helpful feedback. Here is brief about my design:

  1. ESB will send external id, contact info (without Id) and email as parameters.
  2. If Contact does exists with provided external id then update contact.
  3. If contact doesn't found with provided external id then look into Lead with same external id.
  4. If Lead does exists with provided external id then update Lead.
  5. If Lead doesn't found with provided external id then search Lead with provided Email Id, if found then update Lead else create new lead.

I suggested to use out of the box enterprise wsdl webservice api to achieve this. As from ESB, there is going to be few IF conditions and out of the box api call. i.e. First query contact with external id to get Contact and if found then update and same for whole flow.

But the architect team is forcing to keep dependency on CRM, means they want me to write apex webservice method where I will first query contact with external id to get contact and then compare each fields to assign with updated values and then update Contact and same for Lead.

I want to know which one is better to use, either out of the box or webservice method to be exposed. There will be one contact at a time to update. What are pros and cons from CRM and ESP perspective?

3 Answers 3

1

Both the approaches looks ok to me with its own PROS and CONS

Using ESB Logic

1)For resource maintaining this will need ESB skills and logic is completely independent of salesforce

2)The error handling needs to be handled in the ESB itself and retry mechanism to be implemented at ESB end .

Using CRM and platform Logic

1)One more apex class and this will need test class and maintenance

2)You still need Enterprise WSDL

3)More apex code to implement error handling logic .

It will depend on Enterprise resources .If company has excellent In house apex developers go for apex else hosting all logic at other end will also work .

3
  • Probably your architect wants to give you more work and make his life simpler so he is pushing you .accept the work and charge hours :D Commented May 19, 2015 at 19:35
  • Do you think about any performance impact from ESB Perspective? i.e if I make 3-4 webservice calls then does it have any impact? Salesforce is providing out of the box api then what would be significance of making a custom webservice method.
    – JavaAster
    Commented May 19, 2015 at 19:40
  • Custom web service will be hard to maintain but you will avoid webservice calls but your no of calls in ESB is higher .Performance I dont see any difference any where .In apex when we write SOQL it needs to be optimized Commented May 19, 2015 at 20:24
0

I would go with the Apex Web Services approach, or, better yet, APEX Rest Service.

  1. You define a contract between your apex web/REST service and ESB. ESB's life is easy as all they do is make a single web service call
  2. You can write rigorous testmethods on your web/REST service and be sure that if the service's contract terms are fulfilled, that you guarantee the results. Hence, diagnosis of issues falls simply to seeing if there is an authentication issue or incorrect argument passing
  3. As a bonus, your web/REST service can log into a custom Log__c all incoming requests for diagnosis of issues at later times.
0

In my opinion, this seems to be a business logic. Hence should reside within CRM. ESB should be focused on routing right data to right endpoint and required transformations.

Also, apart from considering technical resources, you should also consider data volume here, as

  • ESB based approach can take up to 3 API calls to handle contact record(s).
  • Apex based approach can reduce it to 1 api call in all scenarios.

So, if you have very high volume and high frequency, then I would suggest using Apex based approach. Otherwise, ESB can be used as well.

You must log in to answer this question.

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