Where Should Business Logic be Handled?

[wcl3y2]

Hello,

We are pretty new to SnapLogic, and are trying to develop guidelines for our developers. We received a best practices document from SnapLogic, and one of the items states to handle application/business logic within the source/target applications, not in SnapLogic. I wanted to get some thoughts and opinions on this.

Say we want to create an integration from our CRM to our ERP that creates AR invoices. One of the fields the CRM provides is invoice type, and we need to do certain logic based on the different invoice types. For instance, we might want to set the invoice date or generate revenue recognition differently based on the different invoice types.

In the scenario above, the best practices document recommends that we should handle the invoice type logic either in the CRM or in the ERP, meaning we have to develop something in the source/target application to handle this logic.

What are your thoughts on the general best practice and the scenario above?

Thank you in advance for the responses.

[vaidyarm]

hey,

I also had same doubt as you are having, however we had it for more complex one.
in scenario you explained, you can make use of ternary operator (like if statement ? do this : else do that) , additionally you can use router also to separate out the result to different flows.

“set the invoice date or generate revenue recognition…”
this should be possible with snaplogic.

however in case more complexity such as looking up from existing datasets and complex multi source comparisons, its better to handle it at application end as offers more functionality.

Thanks

[wcl3y2]

Thank you for the response. I definitely agree that is easily doable to handle this type logic in SnapLogic, and I personally think it makes sense. I’m just curious as to why they state that application/business logic should be handled in the source/target applications over SnapLogic. Perhaps my definition of business logic is different than theirs.

[SriVinayaga]

As a integration layer, the tool is always expected to apply some level of logic to transformation or conditional routing. Business Logic is a very wide terminology, and it should be propagated to integration layer only if it is complex in implementing either at source or destination. For the given scenario, it is complex to implement in Source / Destination layer, so nothing wrong in implementing in Snaplogic. Based on the acceptance, there might be a scenario where all the business logic will be pushed to Snaplogic, you got to discuss with the Integration and Enterprise Architect and let them take the decision on where the business logic should be. This is completely my opinion based on my experience in Integration area.