Open APIs

 View Only
Expand all | Collapse all

service validation and characteristic value validation rule in Service Catalog (TMF633)

  • 1.  service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 16, 2022 05:02
    Hello,

    I am implementing TMF633 API for an existing service catalog.

    In existing service definition, there are service validation rules, and characteristic value validation rules.
    And there are different type of rules,
    Simple rule, for example service exclusion rule, is defined with type and scope.
    Complicated rule includes script (which returns back boolean during evaluation).

    How to present those validation rules in TMF633 Service Specification model?

    TMF633 ServiceSpecification has ConstrainRef. Is this the one should be used for service validation rule?
    If yes, CharacteristicSpecification doesn't contains ConstrainRef, where should characteristic value validation rules go?

    Thanks
    David Xie

    ------------------------------
    David Xie
    Hansen Technologies
    ------------------------------


  • 2.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 16, 2022 08:21
    Hi David
    In v4 of the APIs, ConstraintRef is what you are looking for, but it is an opaque reference since we don't have a model or API for Constraint.
    In v5, we plan to introduce a Policy authoring API, and to deprecate ConstraintRef in favor of PolicyRef. We now need to decide where to introduce PolicyRef in the P/S/R/E catalog entities.
    Your feedback is useful, CharSpec would be a possible location to add policy rules.
    Thanks

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 3.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 16, 2022 13:40
    Thanks Jonathan for your quick response.




    ------------------------------
    David Xie
    Hansen Technologies
    ------------------------------



  • 4.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 16, 2022 15:21
    Hi Jonathan,

    I have one more question regarding Constrain/Policy.

    Using PolicyRef in Service/Char spec can simplify the catalog model by pushing them out of catalog spec scope.

    But it can be hard for adding TMF633 API on existing catalog.

    For example, the catalog I am working has three type of rule/policy:

    1) business policy, for example 5G service is only for premium account. Service Spec has PolicyRef pointing to spec managed by Policy Manager.

    2) reusable technical rule, for example MAC address validation rule and phone number validation rule.
        Those rule is managed inside catalog together with Service Spec.  service/char spec has constrainRef

    3) non-reusable technical rule, for example min/max string length.
         Those rules are directly included in server/char spec as constrain array.

    Should TMF 633 support those models instead of having PolicyRef for all?

    Regards,
    David Xie



    ------------------------------
    David Xie
    Hansen Technologies
    ------------------------------



  • 5.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 18, 2022 07:09
    Hi David

    I suggest that you separate between interface and implementation.

    The TMF Open APIs define exposed interfaces. They are (mostly) agnostic regarding how the interfaces are implemented. There is nothing to stop you from having multiple software components each responsible for different part of rule definition, and yet exposing the rule authoring as a single united interface. I think TMF architects would actually find it difficult to sanction having multiple rule representations at the same level just because there's a specific service catalog out there that does this.

    Hope it helps

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 6.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 19, 2022 03:11
    Hi Jonathan, David,

    I second the idea of adding policy rules in CharacteristicSpecification. I have the same need in ProcessFlowSpecification / TaskFlowSpecification.

    At the time being, as policy rules are not yet supported (also in beta release 22.0.0), we are considering to use the "@valueSchemaLocation" attribute for this purpose.

    @Jonathan Goldberg - I am curious what you think about this idea.

    Best regards,
    ​​

    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------



  • 7.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 19, 2022 05:03
    Opher, I don't think that the valueSchemaLocation is relevant for business rules
    I'll open a JIRA issue for the characteristic spec enhancement, but I don't think any discussion of this will happen in the next two weeks due to the holiday season.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 8.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 19, 2022 05:15
    Thank you, @Jonathan Goldberg.

    I absolutely agree with you as for business rules.

    I was more thinking of the technical rules that David was talking about, both reusable and non-reusable. What do you think about using valueSchemaLocation for them?

    Best regards,



    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------



  • 9.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 19, 2022 09:42
    Thanks Opher, valueSchemaLocation could be a solution for some type of validation rule. But it is difficult to change, import and export.


    Thanks Jonathan for your response. I totally understand that. As API, it has to be simple and generic from implements.
    Sorry to be troublesome, I have one more thinking regards the constrain change.
    Is it possible:
    1) Service/Char Spec has list of plicy or constrain
    2) If policy doesn't has href, it is a value, which is for non-reusable rule
         Of cause, there will be Spec regarding the value. But not go there now.
    3) if policy has href, then it is a reference to policy in external domain or reusable rule.







    ------------------------------
    David Xie
    Hansen Technologies
    ------------------------------



  • 10.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 21, 2022 09:28
    Hi Jonathan,

    There is regex in SpecChar:

    regex    A string. A rule or principle represented in regular expression used to derive the value of a characteristic value.

    Will it be deprecated after introducing policyRef or constrainRef in SpecChar?

    Regards,





    ------------------------------
    David Xie
    Hansen Technologies
    ------------------------------



  • 11.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 25, 2022 04:08
    Hi David
    I don't see why we would want to deprecate the existing validation assets. These allow a simpler expression of the validation rules, and are probably easier to author as well. The link to Policy will allow arbitrary validations and other business rules to be applied.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 12.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted Dec 28, 2022 06:13
    Edited by Koen Peeters Dec 28, 2022 06:14
    Hi,

    Validation is often a multistep process. In most cases it is better to detect obvious failures early on in the process. The most common cause of error is data entry. Data entry errors can be avoided in the UI code. The basic validation rules in the catalog roughly match the standard HTML Form capabilities.

    One of the most significant features of modern form controls is the ability to validate most user data without relying on JavaScript. This is done by using validation attributes on form elements.

    • required: Specifies whether a form field needs to be filled in before the form can be submitted.
    • minlength and maxlength: Specifies the minimum and maximum length of textual data (strings).
    • min and max: Specifies the minimum and maximum values of numerical input types.
    • type: Specifies whether the data needs to be a number, an email address, or some other specific preset type.
    • pattern: Specifies a regular expression that defines a pattern the entered data needs to follow.
    If the data entered in a form field follows all of the rules specified by the above attributes, it is considered valid. If not, it is considered invalid and will not be submitted to the server. This type of validation is called syntax validation.
    Patterns are used to define the syntax of structured data (MAC-Address, IP-Address, BIC-Code, E.164 Phone number, ...)

    The policy defines much more complex rules that can typically not be detected in the UI because they require lookups in inventories or other complex operations:
    • E.164 Number must be on-net (including ported numbers)
    • BIC-Code must be of a bank not sanctioned by the government
    • The IP-Address must be geocode into a country

    To summarise the regex, range, ... UI validation rules and the (buiness) policy rules serve a different purpose. It would be a mistake to remove first type of rules because the second type is introduced.


    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 13.  RE: service validation and characteristic value validation rule in Service Catalog (TMF633)

    TM Forum Member
    Posted 30 days ago
    Absolutely agree Koen

    But just to clarify - even the simpler rules need to be enforced in the backend, under the Zero-Trust paradigm. We cannot assume that the consumer of a POST API operation did any validation before submitting the POST.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------