Importing multiple bapi's

[Former Member]

Hi,

In a java web dynpro app I am desiging I am going to make use of some 20 bapi's. My question: what is the recommended architecture in this case? Do I create two, three models and put 6 bapi calls in each one? Do I create two DC's and put one or two models in each? Any good suggestion is highly appreciated.

Furthermore, can putting say 20 Bapi's into one DC affect the JCO performance and cause occasional disconnections?

Thank you for your expertise.

Sincerely

yuval peery

[Former Member]

Hello peery,

Read This -

Recommendation 1: Put all the BAPIsthat you call in the same system into the same model!

Recommendation 2: If you canu2018t follow recommendation 1, make sure that the two models synchronize their (JCo) connections!

// two separate model instances are created ...

MyFirstModelTypemodelMyFirst=

(MyFirstModelType) WDModelFactory.getModelInstance(

MyFirstModelType.class,

WDModelScopeType.APPLICATION_SCOPE);

MyOtherModelTypemodelMyOther=

(MyOtherModelType) WDModelFactory.getModelInstance(

MyOtherModelType.class,

WDModelScopeType.APPLICATION_SCOPE);

// ... but the first model manages and provides the

// connection for the other model

modelMyOther.setConnectionProvider(modelMyFirst);

regards,

Sumit Malhotra

[Former Member]

Hi guys

Thank you all for your elaborate replies which have helped us tremendously in choosing what path to take

Rewards awarded.

If I have a system that runs almost faultlessly on one QA system and after transporting it to production I get endless JCO disconnections the question I ask myself is whether a poor design of the model object lead to such behaviour?

Thank you in advance for your support

yuval peery

[Former Member]

Hi yuval,

in my experience systematic disconnection are triggered by a number of connections that exceed the pool size.

In QA use the web dynpro console to monitor your jco pool.

http://<server>:<port>/webdynpro/dispatcher/sap.com/tc_wdtools/WebDynproConsole

and look under Monitor -> JCo Connection Pools

Bests

[Former Member]

Hi Marco

Is it possible to increase the pool size?

is it advisable?

The thing is I received a badly designed application and until I redesign it from scratch

I want to help the users by making it temporarly working.

Thank you

yuval peery

• you learn a new thing every day, but eventually you die stupid. ****

[Former Member]

Hi yuval,

yes it is possible increase the pool size, from the web dynpro Content Administrator.

http://host:port/webdynpro/dispatcher/sap.com/tc_wdtools/Explorer

and choose Maintain JCo Destinations.

You should do so carefully analyzing the requirements of your application. In particular you should consider the total number of concurrent users because the backend system has a maximum number of concurrent connections: default is 500, but you can override it with parameter gw/max_conn. Pay attention that 6.40 or less have an hardcoded upper limit of 2000 connections.

At the same time each connection consumes nearly 200kb of memory, so this may be a problem if you resources are heavily constrained.

Regards.

[Former Member]

Hi yuval,

pay attention that by default each model estabilish a separated JCO connection with the backend. SAP suggests you put all of your RFC in a single model object. If this is not not possible you should use the method "setConnectionProvider" to share a single connection among the models.

Look here for mode details

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/11c3b051-0401-0010-fe9a-9eabd9c2...

You should also put the model in a separated DC and evaluate the feasibility of a service component who expose the bapi as methods.

[Former Member]

HI

For optimizing the performance of a single edit-deploy-run cycle, the deployment granularity plays a decisive role. Consider the following rule of thumb regarding the separation of Web Dynpro models.

Principally, Web Dynpro models should be separated into separate (model) DCs (one model per DC). These models can be referenced in other Web Dynpro components based on a defined DC usage.

It is a better strategy to separate models into another DC and expose them as public parts. Typically, models contain classes that do not change during development, especially if the interfaces have been defined thoroughly. Since it is optional to build dependant components during design and build time, the development component that holds the models can be excluded from the build, thereby reducing build time as well as deploy time.

Since Different DCs are not allowed to share the same namespace, placing each model in a different DC enforces the following rule:

Put each model in its own namespace or Java package.

Thanks,

Tulasi.Palnati

[Former Member]

Hi,

My experience says put all the realated function modules in a model object. If we are doing so we will be able to differentiate the model functions. Jco conntions are not dependent on no of fun module but the no of cuncurent connections. If you feel all the function modules are related and needs to be put in one model object you can as well do that.

If you look into any performance related documents in Sdn they say the same too.

Regards,

Arun.

[Former Member]

Hi,

the below pdf help you

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/11c3b051-0401-0010-fe9a-9ea...

Thanks,

RameshBabu.V