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


This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].