Extend error states

[maximilianong]

Description

Enhance the error handling mechanism for the orchestrator and gate components by extending the list of available error codes. This will improve the visibility and detail of error information, particularly beneficial for the customer dashboard to understand why a data set could not be processed.

Currently, the orchestrator and gate components have a limited set of error codes. Extending these error codes will provide more granular information on processing failures, aiding in quicker diagnosis and resolution. This feature will update both the orchestrator and gate components to support a more comprehensive list of error codes.

Benefits

• Improved Transparency: Customers can view detailed error reasons on the dashboard, enhancing trust and user experience.
• Enhanced Debugging: Developers and support teams can identify and resolve issues more efficiently with detailed error information.
• Better Monitoring: Allows for more precise monitoring and logging of errors, leading to improved system reliability.

Camel case:

naturalPersonError,
bpnErrorMissingParent,
bpnErrorNotFound,
bpnErrorTooManyOptions,
mandatoryFieldValidationFailed,
blacklistCountryPresent,
invalidSpecialCharacters,
mandatoryFieldMissing,
mandatoryIdentifierMissing,
identifierTypeUnknown,
bpnlChanged,
unclearEntity,
unknownSpecialCharacters,
matchBasedOnProvidedNameOrIdentifier,

By extending the list of available error codes for the orchestrator and gate components, we enhance the system's transparency, debugging capabilities, and overall reliability. This feature will provide significant value to both customers and the development team by offering more detailed insights into processing errors.

Dependency: This feature could be relevant for every product or user who is integrating the gate. FYI: @evegufy / @MaximilianHauer

Additional information

• [ ] I'm willing to contribute to this Contribution will be done by @kunyao-cofinity-x Committer to support are: @nicoprow / @maximilianong

[maximilianong]

Standard adaption might need to be done: 0076 / 0074

Will be taken to a deep dive session with this one: https://github.com/eclipse-tractusx/sig-release/issues/726

[nicoprow]

Description

Enhance the error handling mechanism for the orchestrator and gate components by extending the list of available error codes. This will improve the visibility and detail of error information, particularly beneficial for the customer dashboard to understand why a data set could not be processed.

Currently, the orchestrator and gate components have a limited set of error codes. Extending these error codes will provide more granular information on processing failures, aiding in quicker diagnosis and resolution. This feature will update both the orchestrator and gate components to support a more comprehensive list of error codes.

Benefits

* Improved Transparency: Customers can view detailed error reasons on the dashboard, enhancing trust and user experience.

* Enhanced Debugging: Developers and support teams can identify and resolve issues more efficiently with detailed error information.

* Better Monitoring: Allows for more precise monitoring and logging of errors, leading to improved system reliability.

Camel case:

//GR Error Code

naturalPersonError,
bpnErrorMissingParent,
bpnErrorNotFound,
bpnErrorTooManyOptions,
mandatoryFieldValidationFailed,
blacklistCountryPresent,
invalidSpecialCharacters,
mandatoryFieldMissing,
bpnlChanged

//Gate Error Code

unclearEntity,
unknownSpecialCharacters,
mandatoryFieldMissing,
matchBasedOnProvidedNameOrIdentifier,
none

By extending the list of available error codes for the orchestrator and gate components, we enhance the system's transparency, debugging capabilities, and overall reliability. This feature will provide significant value to both customers and the development team by offering more detailed insights into processing errors.

Additional information

* [ ]   I'm willing to contribute to this
  Contribution will be done by @kunyao-cofinity-x
  Committer to support are: @nicoprow / @maximilianong

The BpnlChanged code is not an error code as far as I can see. It is a comment or success code that the orchestrator currently does not support. We should remove it from this list.

Also 'None' is not necessary to include, as no error is indicated by a NULL value of the error type field.

Is there a reason why we divide the error codes into Gate and Orchestrator? I would assume at least all errors of the Orchestrator should be visible in the Gate (maybe not all errors of the Gate in the Orchestrator though)

[stephanbcbauer]

After a brief consultation with Sebastian, the feature is set to 'backlog' status. Associated committer is also fine with it.

[maximilianong]

In a last refinement call we added the following to attributes: identifierTypeUnknown, mandatoryIdentifierMissing,

need to be discussed: will both be added finally to the reference implementation?!

[stephanbcbauer]

put the open decision label cause there is discussion needed

[MaximilianHauer]

Hey, if you write the testcases for this topic please ensure to have also an E2E testcase for the portal in scope. we do not assume that it should have any benefit on us but a quick check doesnt hurt.

[Phil91]

As long as the SharingStateType is not changed the portal does not need to do any adjustments, we take the error codes just as string and use them. Our current implementation of the SharingStateTypes are the following:

Pending = 1, Success = 2, Error = 3, Initial = 4, Ready = 5

@nicoprow can you please confirm that the SharingStateType will stay the same?

[nicoprow]

As long as the SharingStateType is not changed the portal does not need to do any adjustments, we take the error codes just as string and use them. Our current implementation of the SharingStateTypes are the following:

Pending = 1, Success = 2, Error = 3, Initial = 4, Ready = 5

@nicoprow can you please confirm that the SharingStateType will stay the same?

The error states affect the SharingStateErrorType and TaskErrorType. The sharing state type is unaffected by this.

Note that the BPDM API does not adhere to a specific order of the Enum values like associating Pending with 1 for example. But I assume that the order here refers to your internal Enum definition, correct?

[Phil91]

@nicoprow thanks for confirming.

Yes correct, the order of the enum values is just for our internal usage