OperationalActivity.get_incoming() returns FunctionalExchange instead of Interaction

[IvanRehder]

While working with the Python Capella API wrappers, I noticed that the method OperationalActivity.get_incoming() does not behave as documented/expected.

Expected behavior:

According to the wrapper definition:

class OperationalActivity(Function):
    def get_incoming(self) -> List[Interaction]:
        """
        Returns: Interaction[*]
        """
        return create_e_list(self.get_java_object().getIncoming(), Interaction)

Calling get_incoming() on an OperationalActivity instance should return a list of Interaction objects (operational-level exchanges).

Actual behavior

Even when the variable is of type OperationalActivity, the result is a list of FunctionalExchange objects (functional-level exchanges), coming from the base class Function:

class Function(AbstractActivityFunction):
    def get_incoming(self) -> List[FunctionalExchange]:
        """
        Returns: FunctionalExchange[*]
        """
        return create_e_list(self.get_java_object().getIncoming(), FunctionalExchange)

So it looks like the override in OperationalActivity is either not applied correctly at runtime, or the wrong wrapper is being used internally.

Steps to reproduce

activities = oa.get_operational_activity_pkg().get_owned_operational_activities()
for act in activities:
    print(type(act))                  # <class 'OperationalActivity'>
    incoming = act.get_incoming()
    print(type(incoming[0]))          # returns FunctionalExchange, not Interaction

Impact

This makes it inconsistent to work with Operational Analysis models:

• In OA, we expect Interactions between OperationalActivities.
• In FA, we expect FunctionalExchanges between Functions.
  But in practice both levels currently expose FunctionalExchange, which breaks the abstraction of the OA layer.

Temporary Workaround

The idea is that both Interaction (OA) and FunctionalExchange (FA) wrap the same underlying Java class (fa.FunctionalExchange). By re-wrapping with the desired Python class you restore the expected OA semantics without altering the model.

def _as_interaction(x):
    """
    Normalize a FunctionalExchange/Interaction-like object to Interaction.

    Returns:
        Interaction or None (if x is not convertible)
    """
    try:
        # Already an Interaction?
        if isinstance(x, Interaction):
            return x
        # If it's a FunctionalExchange, re-wrap around the same Java object.
        if isinstance(x, FunctionalExchange):
            return Interaction(x.get_java_object())
    except Exception:
        pass
    return None

Suggested fix

• Ensure that OperationalActivity.get_incoming() (and similarly get_outgoing()) consistently return Interaction objects as defined in the wrapper.

[ylussaud]

Thank you for reporting this bug. In the Capella metamodel there is only one class FunctionalExchange for both Python types Interaction and FunctionalExchange. I think some code is missing in EObject.get_class() to distinguish both cases. But I'm not sure how we can how we can check that. Looking for the containing architecture is probably not a good idea for performance. If you have an idea let me know.
An other way to do this would be to change the List implementation to wrap to the given Class if its assignable to the type that has been found using EObject.get_class(). In Java_APi.py the method JavaIterator.next() could be changed to:

    def next(self) -> T:
        """Gets the next element"""
        if iteratorHasNext(self.get_java_object()):
            nxt = iteratorNext(self.get_java_object())
            specific_cls = self.e_object_class.get_class(nxt)
            if specific_cls is not None:
                if issubclass(self.cls, specific_cls):
                    return self.cls(nxt)
                else:
                    return specific_cls(nxt)
            else:
                return self.cls(nxt)
        else:
            raise StopIteration

Let me know if the path solve this issue.

[ylussaud]

Let's continue on the issue #252.