Multi DC architecture

[Former Member]

We are currently building a web dynpro application and we want to use multiple development components to achieve this.

I would like to know if anyone attempted this kind of project before. We read a lot about the cyclic dependencies problem with CBS and found a way to separate the api and the implemention in two different web dynpro DCs. We now have DCs that implements other DCs (through their web dynpro component interface). We know that it is possible to create a component at runtime or to redirect the component usage but the latter is not currently supported by the web dynpro API.

We tried different design approach but we always had problems with declarative navigation (plugs) in multi DC architecture.

We feel that it is very hard to reuse existing DC instance with declarative navigation.

Did anyone try this kind of architecture?

[Former Member]

Hi Barthelemy,

which problems did you have with the plugs?

Regards

Stefan

[Former Member]

Since you cannot use the referencing mode of the component usage when using UI navigation, a new component must be created every time you navigate from one view to another (if they are from different components). Hence, if you want to return to the last view, you’ll have to create another component and you’ll loose the context.

We also tried a more programmatic approach where component A has a plug to navigate to component B. If component B wants to navigate to component A, it uses a method available from the interface controller of A. Then, the interface controller fires an event and one of its existing views catches it. The problem arises when you want to use plugs to navigate within the component views after that: the runtime does not know from which view assembly the view exists and throws an exception: “cannot navigate from view ProxyView because it is not part of the current view assembly”.

I don’t know if there are ways to solve those kinds of problems…

Thanks,

Barthelemy

[Former Member]

Hi Barthelemy,

i'm not quite sure, if i got it right, but maybe this is, what you're looking for:

A. Prerequisites:

I assume, you have created 4 components. Component UCM acts as the used components manager, which controls the manual lifecycle of 3 Component usages USA, USB and USC. USA..USC refer to the same or different interface definition(s) which is/are implemented by the components you want to use for the navigation.

I assume different interfaces here, which all have in common (for simplicity the event/ifview names are the same, but can be different of course):

1. An (non startup) inbound plug named "FromDispatcher" in their interface view "WorkInterfaceView".

2. Two events named "ToPreviousStep" and "ToNextStep" declared in their interface controllers.

UCM has 3 declared methods createUCA..C(), where the components are lazily built, here's the A "type":

public void createUCA( ) {
  //@@begin createUCA()
  if (! wdThis.wdGetUSAComponentUsage().hasActiveComponent()) {
    wdThis.wdGetUSAComponentUsage().createComponent("UsedACompName", "UsedACompDeployableObj");
  }
  //@@end
}

B. Visual/navigational/event design:

It's important, that UCM has a visual part, which stays visible (part of the current view assembly) all the time, since it's not possible to navigate from "nowhere" to something else. Here is one possibility to achieve that:

UCM has a view UCMV which contains a ViewContainerUIElement (maybe as only element). In the window "Work" of UCM, UCMV is added as single and default visible. The interface views of the component usages USA..C are added to the ViewContainerUIElement-container of UCMV, none of them is default visible. UCMV gets 3 outbound plugs ToUCA..C which are linked to the inbound plugs "FromDispatcher" of the "WorkInterfaceViews" of USA..C. UCMV registers handlers at the events ToPrevious-/ToNextStep of the component interface controllers in USA..C. Here's the handler navigating from A to B:

//@@begin javadoc:handleUSANext(ServerEvent)
/** Declared validating event handler. */
//@@end
public void handleUSANext(com.sap.tc.webdynpro.progmodel.api.IWDCustomEvent wdEvent )
{
  //@@begin handleUSANext(ServerEvent)
  wdThis.wdGetUCMController().createUCB();
  wdThis.wdFirePlugToUCB();
  //@@end
}

Another possibility is using a ViewSet in the window of UCM, where UCMV is the default visible and single element of one view area, adding the interfaceviews of USA..C to another view area.

C. Runtime

Since there's the hasActiveComponent() check in the createUCx() methods of UCM, the components are not recreated and their "state" is preserved. UCMV triggers the navigation to the desired interface views, when receiving the corresponding ToNext/ToPrevious events, which can for example be fired by action handlers of Previous/Next buttons in the views of the used components.

Hope that helps.

Regards

Stefan

[Former Member]

Thank you very much for your input on this issue.

We tried 5 different architectures and the last one was very close to yours. The missing puzzle piece was the ViewContainerUIElement.

By using this, we get rid of the "not in view assembly" exception and we get a clean and generic design.

Again, thank you very much,

Barthelemy

[Former Member]

Hi Barthelemy,

If you are interested in learning more about DCs, please take a look at the help portal:

http://help.sap.com/saphelp_nw04/helpdata/en/ae/1ae58540ea454db1aa14fd635bc10d/content.htm

There are examples and code samples available as well, e.g. Using Functions of other DCs - Example: Using a foreign Web Dynpro Component:

http://help.sap.com/saphelp_nw04/helpdata/en/b1/d1e4f7c633fb47ac8b115087d5f2b6/content.htm

Hope this information is helpful for you as well.

Best regards,

Karin