The thing I struggle with in this approach is now you have spread your IT
department into areas that make it more complex to maintain home-grown
software. You now have business logic in two locations for the same
application. If a helpdesk ticket gets created for a bug, it will most
likely always involve two people to address the issues (i.e. a .NET and RPG
programmer) vs. just one. Obviously this wouldn't be a problem if everyone
in your shop knew .NET and RPG well - but I find that personality a rare
breed.
Just to clarify, I am all for modernization of existing apps. Each of us
are responsible for calculating risk of approaches and long term ROI. If
.NET has been factored in as an acceptable medium to attain modern apps then
I assume the cost to do so has been digested and agreed upon by the general
IT personnel.
With that said, I get the feeling your approach is an easy way, today, to
address your business needs. I think having business logic in two different
languages and platforms will eventually cause some fallout and you will
modify your approach to keep it in one or the other (i.e. in .NET or RPG).
I agree that .NET and/or Java needs to play a role in today's modernization
strategy (talking desktop), but I disagree with where you have placed
portions of your application. But I think we could debate that all day, and
I don't have all day, so I will just leave it at that :-)
On the web side, I can't see why people would go ASP.NET instead of
purchasing a package like Profound Logic's RPGsp which is 100% RPG _and_ it
has wizards to get you up and running fast. The cost of the product could
be paid for in months vs. the cost of having to entertain two knowledge sets
in one shop. Note that I am not completely biased towards RPGsp, it is
simply the only one I have seen that is 100% RPG and doesn't require you to
learn a new language (i.e. like Genexus).
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Monday, October 08, 2007 8:42 AM
To: Midrange Systems Technical Discussion
Subject: RE: .NET with System i5 - where to draw the line was->RE:
NogivinguponSystem i (was: I'm about to give up)
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
