Re: data collection

["Genyphyr Novak" <novakg@xxxxxxxx>]

Hi,

The ECM product actually uses SMGs to get the data into BPCS.

The SMGs (Semantic Messaging Gateways) allow you to post data from outside
of BPCS through normal BPCS programs into the BPCS database. The connection
to the SMGs is up to you to define if you are writing your own front-end -
it can be batch processing, data queues or interactive. They exist from
6.0.02 and higher releases of BPCS.

The required data is mapped into BPCS programs via map files designed for
each programmic gateway. Gateways exist for a large number of base BPCS
programs (availability is dependent upon your BPCS release). The data is
sent in any order using the SDO 'tagged' format as a 'message' through the
SMGs, which pass it into BPCS through the already existing Client/Server
display program interface. If required data is missing or invalid, a normal
BPCS error will be sent back through the messaging infrastructure to the end
application using the gateways. The interface to the SMGs can be customized
to suit your needs (ie, outside programming is required to implement the
SMGs).

However, some ready-made solutions for specific BPCS functions using SMGs
already exist and are marketed by SSA GT (including the ECM product, and the
Lotus Connector). Contact your SSA GT Sales Representative to find out more
about any of these products.

Future development plans exist to provide even more functionality and ease
of implementation in this area of interoperability - via use of XML and
other new technologies.

Thanks,

Genyphyr Novak
SSA GT

----- Original Message -----
From: "Jim Raper" <JRaper@rigltd.com>
To: <bpcs-l@midrange.com>
Sent: Friday, January 25, 2002 8:20 PM
Subject: data collection


If BPCS 'bar coding' were elevated a more generic discussion on BPCS
'wireless data collection' it might be an interesting discussion for all.

First, to clarify, my paychecks come from the Richmond Information Group,
Ltd.  I have partiality.  I will do my best to put it aside.

In the market place there are at least four viable ways to approach wireless
data collection, and many iterations on a theme:

1.  Hook the wireless network directly to the box loaded with BPCS, create
skinny custom screens and use some flavor of terminal emulation.
2.  Use an application to create transaction screens and a server layer to
control the wireless devices and communication to the host to support
terminal emulation.
3.  Use an application to create transaction screens, perform data element
validation, and control communication with the wireless network and the
host.
4.  Use an application to replace BPCS transaction processing, collect and
validate data, update BPCS tables, and control communication with the
devises and the host.

BPCS has two SSA/GT supported methods for accepting data from external
sources: CIM/Path in older versions and ECM in versions after 6.02.

Considerations:

-How often is the host unavailable to process transactions; month end,
nightly backup etc.?
-How valuable is increased velocity of transaction processing?
-Where do you want to manage errors - at the source, while the data is being
collected and before the transaction is processed or on the host after the
transaction fails?
-Would you like to use your data collection infrastructure for something
other than inventory transactions?
-Would it be a benefit if some if not most of the values required to support
a transaction could use the relationships in the BPCS tables to collect the
rest of the information; i.e. for a PO receipt, the PO, and PO line
determines the item, unit of measure etc...
-Do you need the data collection infrastructure to process transactions and
update data in two places? BPCS and a legacy system or BPCS and another
transaction system running in parallel?
-Is it be a benefit to be able to have the identical screens on a wireless
and a desktop device?
-Would it be a benefit if your wireless infrastructure could be used for the
next version of BPCS as well as another ERP system that senior management
might be considering?
-Is your preference a user configurable and maintainable tool vs. one that
requires and IT resource.
-Will your transactions change over time.  How much effort should it take to
add or change a transaction in your data collection infrastructure.

Of course there are many other considerations that will determine a decision
to move forward or not, go big or go small, the key thing for most of us, is
that BPCS is king of the hill.  For most of us, other systems exist to
complement our BPCS applications that so much effort was put into
configuring.  Wireless data collection should make transactions more
reliable, faster, and accurate.  It can do all of that and a whole lot more.

James L. Raper Jr.

The Richmond Information Group, Ltd.
* Manufacturing & Technical Consulting
* DistinctRF
* InfoMark 360° survey processing & administration

jraper@rigltd.com
804.965.9156 x312
www.rigltd.com