• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 519
  • Last Modified:

BPCS Resources

My task is to establish integration protocols between BPCS and various MS applications. I would like some advice from a person that does this or has done in the past: what should I be aware of when updating data into BPCS to make sure that interfacing between these systems happens smoothly and quickly? I cant exactly use an ODBC driver and talk to the database directly since this has proven to be time consuming and problematic in the past.

Any help and advice about how to do this properly would be fantastic
0
nosoup
Asked:
nosoup
  • 3
  • 2
1 Solution
 
tliottaCommented:
nosoup:

Can you elaborate on "time consuming and problematic" for ODBC?

In particular, ODBC has been a performance issue when the client uses it improperly or the server (your AS/400 in this case) is not well configured.

As far as server configuration goes, if that's the major problem, then alternatives database access will likely have the same problem.

Further, there are at least two distinct groups of ODBC drivers. They connect and communicate through two different AS/400 database host servers.

Tom
0
 
nosoupAuthor Commented:
All I have been told is that using an ODBC driver took up to 28 minutes when performing certain operations then when they tried using OleDb that came down to 15 or so minutes but with ASP Web Services and by communicating with the AS/400 in it's "native language" these same operations took < 1sec. I think I am expected to take the web services they have made already and establish them as a common interface to BPCS using this technique. Personally I would prefer to get to the bottom of why ODBC is behaving so badly and bypass this whole "native language" step (but thats just me!)



0
 
tliottaCommented:
nosoup:

Well, I not sure anybody will argue that if a reasonable form of native services can be used, ODBC or OLEDB will ever match the performance. But it's hard to say much without some knowledge of what the "native services" are nor the type of data access.

For example, if the data involves common SQL sets of rows, i.e., a WHERE clause that references multiple rows, most SQL clients can be made to perform similarly and "native services" will probably work about the same. But if any significant number of unique row operations are involved, i.e., row-level access, then it's almost a given that SQL won't come reasonably close regardless of whether it's ODBC, OLEDB or anything similar.

That's just the nature of database operations. Native anywhere can pretty much outperform SQL for row-level access. And there's nothing to stop "native services" from using SQL anyway, so any SQL advantages can be used by those native services whenever it makes sense.

However, OLEDB (and related) is likely to a better choice than ODBC in my experience. And OLEDB can be used to invoke native services and even provide row-level access.

Can you provide much info about size and version of the BPCS host?

Tom
0
 
nosoupAuthor Commented:
I have had a 5 minute explanation of what I am expected to do and do not have any further information about versions or what the native services being used are. This is a new field for me and Im trying to prepare as best I can.

If you could elaborate on what the native services might be (are they an API for performing certain manufacturing operations? or essentially just stored procedures?)  Also you mentioned using OleDb; could you please expand on this as well?

Your help has been really useful so far!





0
 
tliottaCommented:
nosoup:

Wish I could say something about "native services" but it's pure guesswork without reviewing the system. I haven't had a BPCS site to look at for some five years and I'm not sure how current that site was.

I suppose highest likelihood is a set of RPG programs that perform native I/O to whichever files would be involved. Such programs could use direct READ/WRITE/UPDATE/DELETE op-codes against specific indexed records. By using record-level access, performance could _potentially_ be an order of magnitude faster (or more) than access through standard host server interfaces.

Beyond the simple performance difference between SQL and native I/O (for record-level operations, not necessarily set-at-a-time processing), there is also a potential benefit if the "native services" are accessed through proprietary sockets interfaces rather than through standard services such as distributed program calls. Standard host server services in environments such as BPCS might (should?) be routed through exit programs in order to control authorized access. A proprietary interface could include integrated authorization and probably be faster and more efficient.

But it's guesswork. I was hoping someone else had more specific knowledge and could ask leading questions of you. Maybe you could be guided on how to dig out what would be useful. Unfortunately, BPCS is more an application than just "AS/400". Any "native services" might be part of BPCS or could be developed in-house by your site's developers or could have been installed by some other third-party.

Tom
0

Featured Post

 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now