Understanding CUFX

There are 4 significant concepts that help to understand CUFX architecture.

1. CUFX is designed for multiple path Navigation. Primarily you can start with an Account or a Party (Read as Member) and navigate through any messages to achieve a business use case. Like a double spoked wheel. We have done this to support the variety of major CORE processing designs.
2. Think of the message classes like LEGO building blocks, you can reorder these as needed to achieve the vast majority of business uses cases utilized by any CU.
3. Unlike tradition REST get messages; CUFX uses a Post operation with a GET override to pass a message body containing the search criteria. This avoids CUFX from having to define potentially thousands of message classes that would be needed for a tradition RESTful get processing.
4. CUFX does not have a referential data model. CUFX has been designed to support the majority of the major core platform paradigms. As such there is more than one correct way to achieve any given business case or design. By presenting a referential model we could infer that it would be the one right way and therefore only support some of the platforms in the current business environment. Our intent is to support the greatest range of platforms to enable the highest levels of standards adoption.