hibersap.cfg.xml must currently be located under /META-INF in the classpath. It shall be possible for Hibersap users to specify a different path.

See forum topic: https://sourceforge.net/projects/hibersap/forums/forum/813163/topic/3705116

Would it be possible to make the place where to hold the xml file dynamic?
I think it would be better when the file is directly located in the source path, like hibernate.cfg.xml or the log4j.properties ...?

regards
Markus Reich

There shall be a possibility to define a JNDI name in Hibersap SessionManager configuration. Hibersap will then bind the Session Manager automatically to JNDI.

Hibersap converters are currently just working with primitive fields. If I want to convert a table or structure parameter, Hibersap has to know to which structure type the JCo structure has to be converted. The converter can then do user-defined mapping from this structure type to another type.

E.g.
@table
@parameter("CUSTOMER_DATA")
@convert(converter = CustomerDataAggregator.class, structureType = CustomerDataLine.class)
private CustomerDataAggregated customerData;

In the example, the converter's responisbility is to aggregate data from the BAPI table and put it into a single object.

The Java code in the introductory example looks much longer than necessary. To make the code shorter, I propose the following:

@Bapi(value = "BAPI_SFLIGHT_GETLIST", implicit = true)
public static class SflightGetListBapi {

    public final String fromCountryKey;
    public final String fromCity;
    public final String toCountryKey;
    public final String toCity;
    public final String airlineCarrier;
    public final boolean afternoon;
    public final int maxRead;

    @Parameter("RETURN")
    public BapiRet2 returnData;

    @Table
    public List<Flight> flightList;

    // Auto-generated constructor omitted for brevity
}

The above code with the implicit = true annotation would be equivalent to the longer code. The annotations @Import, @Export and @Parameter would be added by the following rules:

• Each final field counts as annotated with @Import
• Each non-final field counts as annotated with @Export (debatable)
• Each @Import or @Export field without a @Parameter counts as being annotated with @Parameter($fieldName$.toUpperCase())
• The type = STRUCTURE is not necessary since the type BapiRet2 is neither a simple type nor a list. Therefore it can only be a structure.

I added the implicit = true to preserve backwards compatibility. Existing code might extend AbstractClass and that abstract class might define fields that should not be parameters.

Hi,
I'm trying the maven plugin https://github.com/hurzelpurzel/hibersap-maven-plugin to generate SAP entities,
I've got the following exception, it looks like trying to read an empty table ! am i wrong ?

Caused by: java.lang.IllegalStateException: Trying to access row values in an empty table which does not have any rows at com.sap.conn.jco.rt.AbstractRecord.checkRowCapacity(AbstractRecord.java:997) at com.sap.conn.jco.rt.AbstractRecord.getTable(AbstractRecord.java:2686) at com.sap.conn.jco.rt.AbstractRecord.getTable(AbstractRecord.java:48) at com.sap.conn.jco.rt.AbstractField.getTable(AbstractField.java:352) at org.hibersap.generation.bapi.ReverseBapiMapper.getParameterMapping(ReverseBapiMapper.java:98) at org.hibersap.generation.bapi.ReverseBapiMapper.addFieldMappings(ReverseBapiMapper.java:134) at org.hibersap.generation.bapi.ReverseBapiMapper.getParameterMapping(ReverseBapiMapper.java:98) at org.hibersap.generation.bapi.ReverseBapiMapper.addFieldMappings(ReverseBapiMapper.java:134) at org.hibersap.generation.bapi.ReverseBapiMapper.getParameterMapping(ReverseBapiMapper.java:93) at org.hibersap.generation.bapi.ReverseBapiMapper.addFieldMappings(ReverseBapiMapper.java:134) at org.hibersap.generation.bapi.ReverseBapiMapper.getParameterMapping(ReverseBapiMapper.java:93) at org.hibersap.generation.bapi.ReverseBapiMapper.mapFields(ReverseBapiMapper.java:76) at org.hibersap.generation.bapi.ReverseBapiMapper.map(ReverseBapiMapper.java:56) at org.hibersap.plugin.GenerateEntitiesMojo.processSearch(GenerateEntitiesMojo.java:109) at org.hibersap.plugin.GenerateEntitiesMojo.execute(GenerateEntitiesMojo.java:95)

Application developers shall be able to register Transaction synchronization callbacks to get informed before and after a transaction is committed or rolled back.
A method beforeCompletion() shall be called whenever a Transaction will be committed; a method afterCompletion() shall be called when a Transaction was committed or rolled back. A boolean argument shall be given to indicate if it was committed or rolled back.

The callback shall be attached to a Session by extending the Session interface for an addTransactionCallback() method. Maybe it makes sense to also be able to register general callbacks with the SeesionManager.

This mechanism works for manual Transaction handling only. With Java EE/CMT the container provided mechanisms should be used.

See https://sourceforge.net/p/hibersap/discussion/813164/thread/90474335/

Thanks to Bigyan Mukherjee for the provided solution.

JCo3 offers the possibility to make stateless calls to SAP, i. e. JCo may use different Connections to the backend system and return them immediately to the connection pool after each call. This allows a more efficient use of connections, e. g. in a scenario with just read-only calls to the backend.
In Hibernate, it shall be possible to make use of this feature. Example:
Session session = sessionFactory.openStatelessSession();
session.execute(...);
...
session.execute(...);
It is not possible to use Transactions here, since these rely on using a single Connection.

Maybe someone has an idea:

If we are calling several RemoteFunctionmodules in sequence everything works fine. If we execute them in parallel we receive the following errorfrom the S4 backend:
UCON RFC Rejected

We noticed, if we switch off the UCON - layer completely, then it works!
The connection is done as RFC WebSocket (with ClientCert-Auth) and use the following environment settings:

JDK: 			SAP Machine 11.0.14.1-sapmchn 
JCO:			3.1.5
HiberSap:		1.4.1

Settings:
jco.client.lang => DE, 
jco.client.client => 102, 
jco.client.wshost => qsw.apps.emaindom.com, 
jco.client.wsport => 443, 
jco.client.use_tls => 1, 
jco.client.tls_trust_all => 0,
jco.client.tls_client_certificate_logon => 1, 
jco.client.trace => 1, 
jco.destination.pool_capacity => 50, 
jco.destination.expiration_time => 60000, 
jco.destination.expiration_check_period => 10000, 
jco.destination.max_get_client_time => 10000, 
jco.destination.repository_roundtrip_optimization => 1, 
jco.client.use_basxml => 1, 
jco.client.serialization_format => columnBased, 
jco.client.network => LAN, 
jco.client.tls_p12_file => src/truststore/keyVault-s4-poc.p12, 
jco.client.tls_p12_passwd => xxxx, 
jco.client.eon_tls_p12_alias => gas-s4-rfccicxxxxxx

Stacktrace

L=[ERROR] TH=[CSCN-Async_3] F=[c.e.c.d.a.s.c.FunctionModuleExecutor] MSG=[class com.emaindom.customerservice.dataaccess.adapter.saprfc.bapis.TaxNumberGetFunctionModule
org.hibersap.HibersapException: Can not get repository from destination WEST_102
	at org.hibersap.execution.jco.JCoConnection.getRepository(JCoConnection.java:163)
	at org.hibersap.execution.jco.JCoConnection.execute(JCoConnection.java:85)
	at org.hibersap.session.SessionImpl.execute(SessionImpl.java:109)
	at org.hibersap.session.SessionImpl.execute(SessionImpl.java:92)
	at com.emaindom.customerservice.dataaccess.adapter.saprfc.common.FunctionModuleExecutor.executeInSession(FunctionModuleExecutor.java:273)

Extend the methods of Hibersap converters to pass field meta data (extracted from JCoField) as additional parameters.

Thus, the Converter could do conversions according to the SAP field's characteristics, e.g. the length of a field:

public Object convertToSap( FieldMetaData metaData, Object javaValue )
{
int fieldLength = metaData.getLength();
String value = (String) sapValue;
return addLeadingZeroes(value, fieldLength);
}

This would convert a number from a representation without leading 0's to the SAP representation with
leading 0's when passing the value Java to SAP: 40000345 -> 00040000345

Alternatively, a meta data provider with the current context might be injected into the converter.

Hi

I got jco version 12 and when I try to use it, it gives me "Illegal JCo archive "sapjco3-3.0.jar". It is not
allowed to rename or repackage the original archive "sapjco3.jar" error, I followed the example which is given in your web site, maven adds version to the file and jco doesnt like that, what should I do?

Thanks.

First of all: Thank you very very very much for this great project which helps me doing things related to SAP in an easy way.

This is not an issue but more like a question:
Are there any plans doing an official release of 1.3.1 (including upload to maven repo)?
Currently I did a build of my own which is hosted in my companies maven repository having it's own release number. This is not my preferred way, but I needed the Changing parameter which was not contained in latest release.

These methods are intended to be called by the application instead of being lifecycle methods themselves and can cause problems or warnings with the JavaEE container.

Up to now, Hibersap was released under the GNU Lesser General Public License (LGPL), being a copyleft license. To make it easier to integrate Hibersap with libraries, etc. released under more permissive licenses, like the Apache license, we will switch to the Apache License, version 2.0.

It would be nice if a converter could get access to the current Hibersap Session, so it can call conversion functions in SAP for a certain field.
Converter implementation classes could use a @Session annotation on a field to tell Hibersap to inject it before calling the convert methods.

Under certain conditions, a NullPointerException is thrown in JCAMapper.mapRecordToFunctionMap(), line 73 (LOG.debug(...)) because recordValue is null.

Update the Maven plugin and library dependencies to current versions.

Libraries:

• commons-logging from 1.1.3 to 1.2

HI Team,
@cerker
I have been using this jar for fetching data from SAP ABAP and do some business logic before inserting into Mongo.
Now we have a reiqurment to fetch data with 100.000 records and more .we get

java.lang.OutOfMemoryError: GC overhead limit exceeded

Is there batch support as supported in Hibernate?

A common problem when bootstrapping Hibersap with JCo is a wrong application configuration regarding the JCo native lib. It would be a great help to see the java.library.path in the logs.

The System property shall be logged in JCoContext or JCoEnvironment before first accessing the SAP backend.

Hibersap is still built with language level 5. We would like to move on and use Java 8 as a basis.

This effectively means new Hibersap versions will not run on Java versions 5, 6 and 7. Developers still using older Java versions will be restricted to use the older versions of Hibersap.

This should come without any API breaks for existing applications.

For import and export parameters, only one of the convert methods is called. Hibersap should provide an abstract default implementation for the Converter interface, where each method throws an UnsupportedOperationException. Thus, developers only have to overwrite the method that is needed.

Currently, Hibersap detects the type of the Collection by analyzing its generic type. It shall also be possible to map BAPI tables to Collections without generic type. In this case, the type has to be defined per annotation or annotation attribute, like JPA's targetEntity attribute in @OneToMany etc.

May be useful also for other parameters so we can map to an interface, abstract class.

To get errors from a SapException, one has to call getErrors() which returns a list of SapErrors. Often, the RETURN parameter is an export structure rather than a table. In this case SapException should offer a getUniqueError() method that returns a single SapError and checks if there is really one one Error. If not, it should throw a runtime exception. It is the application developer's responsibility to call the correct method.

The hibersap-ejb library implements the HibersapSession annotation and HibersapSessionInterceptor which can be used to automatically inject a Hibersap session into an EJB. With this approach, the application developer is responsible for opening and closing transactions on the session in order to commit/rollback the transactions in SAP.

JavaEE offers a transaction synchronization mechanism where a javax.transaction.Synchronization implementation can be added to the current exception which will be notified when a transaction is completed, i.e. right after the Tx manager committed or rolled back the other resources.

Additionally, the synchronization mechanism gives the possibility to store data in a transaction context, which should be used here to store a Hibersap session for later use in the HibersapSessionInterceptor, when the Hibersap sessions need to be committed or rolled back. Now the sessions are stored in the context data of the InvocationContext. The transaction context is a much better place, since it behaves correctly even with nested transactions.

The Hibersap EJB component shall make use of this by registering a Synchronization object with every transaction where a HibersapSessionInterceptor is used and store the Hibersap sessions in the transaction context. After the container has completed a transaction, the synchronization object shall commit or rollback the Hibersap transaction which effectively will commit or rollback the transaction in SAP.

This is not a watertight transactional approach since it is still possible that a commit in SAP fails while at this point the other resources that take part in the (distributed) transaction are already committed. However, for most use cases this should be sufficient. If real distributed transactions are needed, application developers should consider using a resource adapter for SAP, like the Cuckoo RA.

Hi thanks for hibersap, the product works really well.
However I wanted to know if we can use CHANGING parameters with it, indeed I didn't found how to do it, thanks for your help.

Since SAP JCo 3.0.11 there is a runtime check that the JCo library file name must be sapjco3.jar. This makes it difficult to handle the JCo jar in Maven projects since the Maven dependency plugin automatically adds the version number to the file name (e.g. sapjco3-3.0.15.jar) when copying from the repository, which leads to runtime errors when using JCo.

A workaround is to name the jar file so that the file name starts with "com.sap.conn.jco" which is also accepted by the JCo runtime check. By giving the Maven artifactId a name which starts with this prefix, Maven names the jar accordingly (e.g. com.sap.conn.jco.sapjco3-3.0.15.jar) which passes the runtime check.

See https://sourceforge.net/p/hibersap/discussion/813164/thread/52913577 for a discussion

To do:

• Rename the artifactId of https://github.com/hibersap/hibersap-sapjco3 to com.sap.conn.jco.sapjco3.
• Use the new artifactId in the hibersap project and example projects.
• Adopt documentation.

Moved this issue from https://sourceforge.net/p/hibersap/feature-requests/32/ for documentation issues since this will be part of the next Hibersap version 1.2.0.

Original post by Henning Hu:

"New Parameter Type "Table" for export Parameter to allow collections of structures."

JCo made a jump in its minor version, so we should test if any API was broken and it still works.
The current version is 3.1.2.
Also, update the JCo version in integration tests to always run with the current version.

Hello,

I think it would be nice if Session and maybe also SessionManager could implement the Closeable interface.

This would allow to use the try-with-resource statement:
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

try (Session s = sessionMgr.openSession()) 
{
   ....
}

As of yet, Hibersap only supports flat structure and table parameters, i.e. ABAP structures that contain only simple field parameters. This is a restriction for the BAPI standard and thus work well in most cases.
However, in the real world, there are ABAP function modules that have deep structures, i.e. structure or table parameters containing other structure or table parameters and so on.
The Hibersap mapping mechanism shall be extended to support these kinds of deep structures.

Moved this issue from https://sourceforge.net/p/hibersap/feature-requests/34/ for documentation issues since this will be part of the next Hibersap version 1.2.0.

Original post by Christian Schneider.

"We currently start to use hibersap in an OSGi environment (Apache Karaf based on equinox). We can already install the bundles by wrapping them manually as OSGi bundles. It would help us a lot if you would already do this.

It should be pretty easy to do this on your side:
Simply add the maven bundle plugin to your parent pom like this:
https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist/pom.xml

Then just switch the packaging from jar to bundle for each project:
https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist/tasklist-model/pom.xml

This will create bundle with default package imports and exports derived from the actual used classes.
This seems to work fine for us.

The bundles are still valid jar files which should work like before in a non OSGi environment.
I can also create a patch if your like.

Best regards
Christian"

Currently, the SessionManager holds a map with Class as key and BapiMapping as value. In applications where Bapi annotated classes reside in different modules which are loaded by different classloader this can lead to problems, e.g. multiple EAR deployments in an application server (like JBoss >= version 7 or Wildfly) with a central module doing the Hibersap configuration.

The map can be changed to have a String with the fully qualified class name. The disadvantage of this change is that we now rely on unique fully qualified class names for @bapi annotated classes. Having different classes with the same fqn should be considered a design flaw anyway, so this should not be a big problem.