File interface or real time interface ?

[Former Member]

Hi,

I have a requirement to interface legacy system with FS-RI. Now, there are two options I have to propose:

1) File interface - Dump the data to text file from Legacy and upload the data in R/3 using some BAPIs which will do some plausibility checks. The program that will use BAPI will be run be shceduled to run two times a day.

2) Use a real time interface like SAP -XI or .NET connector - This kind of real interface will exchange the data in real time as soon as the data in created in legacy instead of using file. Even if I use this interface, we have to figure out a way to deal with error-handling.

I would like to know what are the advantages and disadvantages of both type of interfaces.

Thanks.

Regards,

Rajesh.

[Former Member]

Any inputs...

[Former Member]

Hi Rajesh,

If you want to propose the methods between two then go for BAPI. because you can create a log files of all the errors. & the data will always be in a particular sequence & format. If you are using any connector the the main disadvantage will be Error Handling of all the records. How you need to also keep track how may records aare uploaded successfully before & after the eror has occured.

In BAPI method if an error has occured then you can move that record in another internal table & the uploading will be continued from the next record.

Ashvender

[Former Member]

No No,

Let me make it more clear. If if we are using .NET connector we have to use BAPI, right ? Because without BAP, the plausibility checks will not be done.

So as far as my understanding when I mean using .NET connector, I mean connector will just connect .NET system with R/3, but we still need to call BAPI in C# (.NET code). Aren't I correct ?

Regards,

Rajesh

[Former Member]

Hi Rajesh,

Yes, you will still have to do your coding either on the ABAP side (e.g. BAPI) or in whatever language you use on on the other system.

The .NET connector is nothing but middleware that builds the bridge between SAP and an external system (at least it was when I worked with it about 3 years ago).

One more thing: you don't really have to use BAPIs, you can also use RFCs with .NET connector.

Also, if you are using some .NET language on the legacy side as well, see my other reply regarding using Web services.

Guenther

[Former Member]

Personally for interfacing, I'd strongly recommend IDOC over BAPI, since you have greater control over when you post the data, error handling, editing and reprocessing tools, and it's far easier to support.

If you absolutely have to use the BAPIs, then in an async scenario this would rule out XI as being a viable option, because what happens if the interface fails?

XI is great, but in an async flat file scenario, IDOC is your only viable option.

[Former Member]

Sorry to disagree Chris, but I think you are jumping the gun here:

<u>"you have greater control over when you post the data" </u>

I am not sure, I completely understand what you mean by that, but I don't think you can have more control than a real time process (i.e. BAPI, RFC etc.) provides.

<u>"error handling"</u>

Yes, with IDocs you can use the standard monitoring tools but on the other side your error handling is always reactive vs. proactive in a real time process. If you can live with that, perfect; if not you are risking data inconsistencies.

Real life example:

in one of my previous projects, we used a 3rd party tool to perform WM transactions; the communication between SAP and the 3rd party happened via IDocs. After going live we found that material that wasn't available in R/3 was shipped out.

Cause: IDocs to tell the 3rd party what material was allocated to orders (and therefore unavailble) in R/3 failed. Before those IDocs could be analyzed, fixed and reprocessed, the material showed up in the 3rd party product as available and was shipped out. We finally had to dump the whole application and rebuild it as a real time solution.

<u>"editing and reprocessing tools"</u>

Agreed, since you will have to build your own process for reprocessing errors

<u>"far easier to support"</u>

Depends (see error handling)

<u>"If you absolutely have to use the BAPIs, then in an async scenario this would rule out XI as being a viable option, because what happens if the interface fails?"</u>

You monitor your interfaces in XI.

<u>"XI is great, but in an async flat file scenario, IDOC is your only viable option."</u>

I would call this a bold statement

My conclusion: wherever possible, I would go real time;

I wouldn't use IDocs in any "close to realtime" scenario where instant monitoring has to be guaranteed (is it ever?) and where a possible delay in analysis and error resolution does NOT bear the risk of possible inconsistencies.

Just my 2 cents...

Guenther

[Former Member]

Well Rajesh,

I think there are multiple factors to consider:

1) What is the overall direction the company is going?

Many companies start considering a more SOA based approach and maybe this could be a good starting point to introduce XI (more below)

2) Implementing a middleware (.NET connector) and especially EAI (XI) based solution comes with overhead (software, infrastructure/hardware, proof of concept etc.), i.e. if you propose XI and they realize the overhead, this might not be an option anymore

3) According to SAP, XI will be required in the near future to run certain modules (e.g. SRM), so the argument made in 2) might not be valid if you have to implement XI soon anyways

4) Time frame: if you need this done soon and have none of the MW/EAI infrastructures in place, the file (batch) approach might be the only one feasible

5) Dependent on the SAP release and infrastructure plus the technical specs of the legacy system, you might even be able to use a Web service based solution which would allow real time communication without implementing any additional middleware

6) Even if you decide to go batch, you could still use XI

In general, I would definitely try to go the real time route, just from a data integrity perspective. Even though your customers might tell you today that syncing the data twice a day, you never know whether one day it will bite you in the back.

Also, since your company seems to be a bigger, financial institution (FS-RI), I would assume they are already evaluating SOA (at least they should), and XI is the (required) platform for SAP's SOA approach (ESA).

XI provides monitoring tools that allow you to check on the data transfer from an XI perspective, so some of the error handling that would have to be coded from scratch (file approach) could be eliminated with XI.

Consider performance, based on data volume you should propose to include performance evaluation in your PoC.

Long story short:

If you don't have a lot of time to implement and support/maintenance costs in the future are not a big factor, file/batch might be the way to go; if you want to propose a solution that will hold up to future requirements and the company is able and willing to support the initial effort, I would go for XI.

I think .NET is somewhere in between and if you can, try to eliminate it by using Web services.

Hope this helps!

Guenther