On 7/6/2017 5:30 PM, Nathan Andelin wrote:
On Mon, Jul 3, 2017 at 11:23 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
In the case of my organisation, .NET running on Microsoft Windows. The
web team get the data via stored procs (mostly) and it took time
convincing management that the web people didn't need ODBC direct to DB2
tables.
Buck, would you be willing to share what convinced your management to call
stored procedures from MS .Net apps?
Sure. My argument went something like this. Giving the front end
direct access to the database has several painful aspects:
1) The .NET team would need to become intimately familiar with the
database. That's a learning curve.
2) When the DB2 team makes database changes, the .NET team will have to
alter their code as well. TWO separate development efforts need to be
synchronised to deploy to production simultaneously. That doesn't sound
that hard, but when we DB2ers embark on a large scale change, we arrange
things so that it fits our schedule. That doesn't mean the .NET team
has the same time available!
The alternative, supplying the .NET team with stored procedures, means
that they neither need to learn about the DB2 hierarchy, they aren't
locked into how we store data, nor are they affected by underlying
database refactoring. Their development schedules don't need to
interlock with ours, and the 'interface' between the front and back end
is more business process oriented rather than field, field, field related.
What do your stored procedures do?
We've tried to go high level, so we've modelled business processes
rather than streaming raw data back and forth. One example is what
customers get to look at. Their role in their company determines what
they get to see: the president can access everything about the company,
her managers get to see stuff about their department, etc.
Rather than pass the role forward to the front end, we pass the
authorisation to them. The business rules were already in existence on
our side; it made little sense to write them again in .NET, and to tie
the .NET rules to our internal DB2 role codes.
This frees us to create new role codes (like president's admin) and
group them together with 'president' in a transparent way. When the
president's admin logs on to the web app, the .NET people don't need to
worry about handling another role code; we tell them this user has
'president' clearance and it just works.
The corollary is that because the rules and database implementation live
on IBM i, we use the same things in various green screen applications
seamlessly. There isn't a divergent view of the customer between green
and web because both sides share the exact same rules.
In addition to 'get this business information' we provide services to
them like 'email a membership card', 'put the customer on this mailing
list' and so on.
As
you intimated, MS .Net developers have other options for retrieving and
updating IBM i data. Do your web developers view you and your stored
procedures as a valued resource? As a gate-keeper? As a bottleneck?
The .NET team would prefer direct access because it's what they do with
the various SQL Server databases they also use. They gently express
frustration when they want a new stored procedure. I believe they do
understand the benefits of decoupling, but since they haven't
experienced a meltdown, the danger seems distant and academic to them.
midrange.com
