Skip to Content
avatar image
Former Member

Architecture Discussions - Central/Local, Central only, Local only?

Hi All,

This question is constantly being asked by customers/clients/partners. So rather than leaving it verbal, I would like to stimulate some discussion here which we can then reference in the MII wiki. I guess I could write a blog, but I think this reaches a wider audience.

I will start off with a suggested reasoning for specific architectures for simply providing a starting point. Feel free to disagree, but please provide your rationale

Central/Local:

By default, I usually lean towards a Central/Local architecture. And by that I mean that there are MII servers in each Production Plant and a central MII server which is the focal point of the inputs to the ERP and other central data center functions. Some folks will point out that this means the central MII server is a potential single point of failure, but that is also true of the ERP system which it presumably interfaces to. Also this simplifies the interface to the ERP system where the RFC/IDoc Listeners are concerned. In the past I also would point out that the use of Virtual Xacute Server connections would utilize a binary streaming feature which is very efficient in transporting data. There are other methods now of invoking the binary transport, but the intent is to minimize the footprint on the network. Minimal data transport with the central MII instance formatting the raw data for ERP uploads via BAPI/RFC or IDoc or ES. The network footprint for the formatted BAPI Request XML is usually a minimum or 5 times greater than the raw data itself.

Central only:

I only recommend this when MII is providing central (generally upper management) dashboards which are utilizing small amounts of data from local plants or only reporting on data which already resides centrally. A simple example is an electricity usage monitoring system. Once a day or perhaps once a shift, the local metering can be queried and the data presented centrally from all the plants for sustainability purposes. Little bit of data, fairly simple presentation, but good corporate data presentation.

Local Only:

A subset of Central/Local which can be implemented first. There are strong reasons to have MII reside at the local plant. Response times are much faster just from being in the local network. When using MII to manage your production data and provide insight for managing the factory, colocating provides disconnected (from Central) operations. More complex data processing is easier to implement when WAN considerations can be ignored. Interfaces to ERP will need to be created and maintained for each plant (speaking again about RFC/IDoc Listeners) and each plant will require its own RFC Destination, etc. in the ERP system. If you are just using MII for managing your local plant(s) with dashboards, KPIs, etc., then a local only makes sense.

These are just quick thoughts and are not meant to be comprehensive. That is for the rest of you to provide (please!). I hope we can generate enough of a dialog to help others make good decisions for their architectures in the future.

Thanks in advance,

Mike

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    avatar image
    Former Member
    Nov 30, 2010 at 10:03 AM

    this is a really interesting topic!!!

    Hi everybody,

    I had experience in the last two years with a local infrastructure of xMII servers running 11.5 version.

    In my scenario every plant has it's own xMII server, being exactly in the middle between Central ERP and local production systems.

    I would say this is not the ideal solution in my mind...

    ...I consider MII something it should be absolutely local, 'cause has to send/receive data from local systems and in the LAN the amount of data transferred can be really high (and has to be fast), but I can say we experienced problems with load balance toward ERP (where ERP it seems to be the bottleneck) and trying to synchronize the calls to the ERP.

    That's why, even if I unfortunately have no experience with this architecture, I would propose in the future as ideal architecture the first solution listed at the top of the thread...local MII servers linked to local systems with a centralized MII server linked to ERP.

    regards

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Michael Appleby

      ...well ERP it shouldn't be the bottleneck, that situation surprised me a lot and I really think it is linked with bad management of ERP infrastructure (maybe tuning and missing scalability of solution once factories live are increasing) and bad communication between the areas (lack of real vertical integration).

      I also think it could be linked to strategic outsourcing all companies are generally doing on IT area...loosing internal human resources...getting globally a worst service from systems on supporting real production...but this is my own poor opinion...

      best regards

      Edited by: ottantaphoenix on Dec 1, 2010 10:19 AM

  • avatar image
    Former Member
    Sep 29, 2010 at 12:51 PM

    All,

    Along with Mike's comments, there are diagrams and corresponding explanations in the [MII 12.X Best Practice Guide|http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/f08d7ae2-6f56-2c10-50b4-8a3bb1d43502].

    Looking forward to seeing your responses....

    Regards,

    Kevin

    Add comment
    10|10000 characters needed characters exceeded

    • Strictly speaking, Load Balancing is handled through NW (and in ECC). There are some aspects of both that percolate down to the MII level. JRA allows load balancing, but not SSO. JCo allows SSO, but not load balancing. There are other aspects as well particularly if you do modifications to IDocs or other ERP mods.

      You will probably need some assistance from NW/Basis resources if you run into any other issues with load balancing. Problems will sometimes pop up where one node receives MII "stuff" and the others do not. Inconsistent processing is a symptom of this.

      Regards,

      Mike