BAPI runs in SE37 but not from MII using JCo

[lawrence_prinsloo]

Hi all,

I'm using a custom BAPI to record QM Inspection Lot data.  This custom BAPI will accept just one sample's worth of data or the whole inspection lot's data (multiple operations / inspection points) depending on what's been sent up.  The key principle though is that it's atomic - the whole set of data must be processed or it must all be rolled back. 

One of the issues we had was when we tried to record multiple samples against an operation, it only recorded the last sample and not the previous ones we uploaded for the operation.  This seemed to be because we didn't commit the data till the end, so the earlier samples were over written by the new samples as the data was processed.  We've modified the custom BAPI to now first create the samples in SAP before we update them with the results and this now gives us what we want - multiple samples are recorded against the operation.

Problem is, when we call the BAPI from SE37, it works without any problems however when we call the BAPI in MII, we get an error saying the Sample has already been created.

<RETURNTABLE>

<item>

<TYPE>E</TYPE>

<ID>QT</ID>

<NUMBER>421</NUMBER>

<MESSAGE>A sample number already exists for the given key fields</MESSAGE>

<LOG_NO/>

<LOG_MSG_NO>000000</LOG_MSG_NO>

<MESSAGE_V1/>

<MESSAGE_V2/>

<MESSAGE_V3/>

<MESSAGE_V4/>

<PARAMETER/>

<ROW>0</ROW>

<FIELD/>

<SYSTEM>QASCLNT500</SYSTEM>

</item>

</RETURNTABLE>

The user account is the same for SE37 and MII.   We're on MII 12.2 build 65

Thanks - would really appreciate some input.

[Former Member · Accepted solution]

Hi Lawrence,

This type of problem occurs when you donot call "BAPI_TRANSACTION_COMMIT" in the loop where you are recording multiple Inspection Results. You need to check for status and commit within the loop itself for each result recording.

As far as difference in executing from SE37 and MII, if the ZRFC  executes "COMMIT WORK", then it will commit only from SE37 because WORK represents R/3 System work process which will not be accessible from MII System. Hence, calling "BAPI_TRANSACTION_COMMIT" is recommended.

I have gone through these things and to solve the above I created a ZRFC where I declared a table parameter where all Inspection Lots and corresponding results were passed.

Firstly I sorted this table by Inspection Lot number and Characteristics number. Then I used ABAP's LOOP...ENDLOOP to record results After every distinct Inspection Lot, I checked for Success/Error and accordingly called BAPI_TRANSACTION_COMMIT or BAPI_TRANSACTION_ROLLBACK.

The output was a RETURN_TABLE where I appended all errors and returned at once. The MII BLS has nothing extra to do except to check this return table whether any  Lot(s) encountered error and what error. This even maximized the performance as there was only one round trip between MII and ERP  ie, Pass Inputs, get the outputs.

Regards,

Prashant

[former_member329434]

Hi Lawrence,

I think it is looking for a unique set of data and not the one which has already posted. Please try with different sample and let us know.

Thanks,

Suman

[lawrence_prinsloo]

Thanks Suman,

but I've tested this with new data multiple times.  The issue here is that using exactly the same data, I can post data to an Inspection Lot in SE37 but not when running from MII WB.  I don't know how the data is processed differently within SAP if it's presented using SE37 or directly from MII.

Does anyone have a suggestion?

[Former Member]

Hi Lawrence,

you can check two points, it may help you.

• If some how samples are getting finally committed while creating the sample in ECC and making the sample unchangeable, So while you are sending data to ECC they are treating it as already exist.
• you can check if the same sample no is passing by any other inspection lot to ECC for a single flow cycle and if the PK in ECC for the samples are same for all inspection lots (if they have no such identifier) then when ever a sample will be updated to ECC for any of the inspection lot it will commit all the other samples of other inspection lots also.

Regards,

suman

[salvatore_castro]

Does the BAPI have any kind of commit/rollback built into the code?  Also, do you have "Automatically Commit" set in the JCo action definition?

Sam

[lawrence_prinsloo]

Hi all,

firstly to clarify the logic in the custom BAPI:

1. Receive IL Data
2. Loop through all Inspection Points and create a record of the Sample ID (placeholder for the results)
   1. If Sample is already there, then don't try to re-create it.
3. Commit the above step
4. Clear cache (it's more to try fix the problem rather than part of the logic)
5. Loop through all the results for each sample and Record the results against the sample created in step 2
6. Commit the above step

If anything fails, the rollback will rollback everything (except the sample place holders as these have already been commited).

I call the BAPI using the JCo action blocks and then depending on the success / fail status, call a commit / rollback action.

Sam, I'm not sure where the option is to Auto Commit - so can't confirm either way.

The key thing here is that the process works from SE37, so there's something different when the BAPI is called from MII - which is different to what I'd imagined it to be.

[former_member185280]

Its not well known but running a bapi in SE37 is actually different than calling the bapi from an external system because SE37 takes into account the functionality built into SAPGUI like date formats & translations etc. Usually it isn't an issue and It may not be here just an FYI.

[lawrence_prinsloo]

Thanks all,

we've decided to break down the amount of information we process at a time.  So instead of processing all of the IL data in one go, we do each sample as it's generated.  Simpler and it works with the standard BAPI if we choose to use that instead.

Thanks for the input.

[salvatore_castro]

Lawrence,

Using standard is always a good idea and you can request to the SAP QM team a "bulk" upload BAPI be rolled into standard product as well. 

On a related side note since you are going the standard BAPI route you may get some value out of this QM Integration example which covers exactly this scenario.  It was built for MII 12.1 originally and if I was to redo this I would leverage MDO and not a database table for staging the data that is to be loaded into ERP; easy enough to change over the content to use MDO.

Integrating MII with ERP QM - This article provides some

insight on how to integrate your MII v12.1 software with the SAP ERP QM module

via JCo. This will allow in-depth SPC material based inspection lot analysis for

single and multiple inspections lots. This document provides both an overview of

the process steps and screens along with detailed steps on how to build your

content within MII and a pre-built example project of all of the content.

Hope this helps,

Sam

[lawrence_prinsloo]

Thanks Sam,

I like the idea of getting the SAP QM team to build that BAPI!  

Otherwise, I used your examples as a template, except we're populating the QM data from the MES layer and not an MII screen / application so the database tables were the simplest option for integration.

Thanks again for the help all.