Do you have an example of when you felt it was better to have the BL
on the
i5 vs. in .NET code.
Oops, didn't mean to not answer this part. Sure, I've got a couple:
We had a case where we needed to update a "customer", however the
concept of a customer was spread out over many data files, including
some that were sill S36 internally described files. By moving the
update-customer logic to a RPG stored proc we could make one call to the
DB to update the customer and let it spread those updates across the
appropriate tables including dealing w/internally described files
w/packed data.
Another example is a data-intensive process, like say determining a
price for a product. Take the case where a product price is determined
by product, class, quantity, customer, other items on the order, etc.
The actual intelligence to calculate the price could be on the System i
or on the PC, but the data is on the System i. The performance cost of
reading all the data from the PC makes this an obvious case where you
want to put that BL on the server and just read the data on the server.
Finally, another reason is to reuse already existing complex business
logic, say a complex BOM process that's already used in the enterprise.
Sure you could recreate the logic on the PC, but why bother. You've got
a perfectly good callable routine on the System i that's been used and
trusted for years and all the bugs are worked out. Why re-implement the
process and risk introducing new bugs. Plus, by reusing the existing
process you maintain a single point of maintenance, fix/change it in one
place and you affect both the PC and green-screen processing.
-Walden
midrange.com
