Hallo Sven,
Let me map your question to a similar one. I assume, my answer is also applicable for your scenario:
<b>Question</b>
<i>Let's say I have an application for which I need to use 2 Adaptive RFC. What would be the better thing to do:
Import each RFC separately so that I have 2 models (one for each RFC) or
Import the 2 RFC at the same time. I would then have 1 model but with the ability in it to access the RFC that I need (when I do the Model Binding in the controller)
At first, I thought that the 2nd method would not be recommended because when I execute the model Object it would actually execute both RFC at the same. But after a test it doesn’t seem to do so.</i>
<b>Answer</b>
Best Practice is certainly to put as many RFCs in a single Adaptive RFC model as possible.
Reasons:
1) a model represents a namespace, therefore, any commonly used datatypes or structures can be shared only within a single model. The best example for this is the "Return" Structure of Bapis (Bapiret2). If you import 2 RFCs (Bapis) in different models, then you will receive two different classes representing Bapiret2. You can therefore no longer build any common functionality for parsing and interpreting the Return Value of multiple Bapis. You can not share references, which means you can not pass data by reference from one RFC to another. Instead, you would be forced to copy, e.g. via the WDCopyService.
2) a model represents a number of services, which are required at runtime. The most important one is the connection (JCO.Client). If you import 2 RFCs in 2 different models, then each model will re-quire a connection to be assigned at runtime. In most cases though, you want to share the connec-tion between multiple RFC calls, therefore it is wise to keep those RFCs in a single model. Remark: It is possible to share a connection between multiple models (see Method IWDDynamicRf-cModel.setConnectionProvider() ), but it is still easier if you are not forced to do this.
3) Reimport functionality exists, so you are able to update an existing model and add further RFCs as needed. In the past, this was often the reason for using multiple models. This problem no longer exists.
You may still wish to separate models, and there are use cases for this. Here are some situations in which you would do this:
1) You need to access different RFCs in different back-end systems, e.g. RFCA accesses SystemA and RFCB access SystemB. This requires uses different connections, therefore, you MUST use dif-ferent models.
2) The lifecycle of the RFCs is different. E.g. RFCA belongs to a different Business Package than RFCB. This could lead to updates in RFCA which would not affect RFCB. If this is known at devel-opment time, then it is wise, to also keep these RFCs independent of each other by importing them into different models. This is usually only the case in larger development projects involving many developers (such as XSS)
3) <i>Componentization</i>: If you make strong use of Web Dynpro components which are contained in dif-ferent DCs, then you may also want to split up RFC Models, to keep them from getting too big, and to avoid unnecessary dependencies. E.g. WD Component A (part of DCA) uses RFCA and WD Component B (part of DCB) uses RFC B. But the two components have nothing to do with each other. In this case, you have the option of either importing a single common model and placing it in a different DC (lets say DCX) to prevent DCA and DCB from getting dependent on each other. Al-ternatively, you can import two different models and place each model in the DC in which it is used: RFCA is imported into ModelA and placed in DCA.RFCB is imported into ModelB and placed in DCB.
Best regards, Bertram
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.