Naming Conventions for Digital Interfaces & Digital Integrations in EA Workspace, Xanadu

[markterringon]

Hello & Happy New Year

We have moved to Xanadu and currently documenting all APIs & Integrations across our landscape.

I wanted to ask if anyone has a ServiceNow naming convention for the naming of Digital Interfaces?

I have seen suggested naming conventions for the Digital Integration, e.g., SAP_to_Salesforce_API_Prod_v1.0, but nothing for the Digital Interfaces.  I wanted to see if there was a common view or approach on this ?

Also, do you add the actual API URL in the description as a way to link the record to the actual API used?

Thanks for your help in advance.

Kind regards,

Mark

[Bruno De Graeve · Accepted solution]

hi Mark T, we do have a current limitation that the Digital Interface name field has been set to 40char. We already encountered that issue and have a story in our backlog to extend it to 120char. 

The Digital Integration name field is already set to 250 as some of the forms will auto-calculate a name for you.

regards, Bruno

[mcastoe · Accepted solution]

Many thanks Bruno!  the additional chars will make a naming convention much more viable.

@markterringon, as for the subscriber Interfaces, they are purely optional.  Some customer see need to model the "api on the other end" if it exists but that is not at all required.   Most i've seen do not use them unless if very clear the subscriber "interface" exists and required soem form of management.  Its sort of a value statement; does thsi record provide me value ? Does it enhance the visibility of how things work?   For me, it better to start simple and get value then enhance the model in use if there is call for it.

thanks,

mark c

[markterringon]

Hello again 🙂

@Bruno De Graeve  Thanks for the update that's great to hear and will certainly help.

@mcastoe Brilliant thank you!   The diagrams I have seen show there is a digital interface for both provider and subscriber - so that was the assumption we were working towards.  But if it is optional then that certainly helps.

Thank you both very much 🙂

Cheers,

Mark

[markterringon]

Hi @brunodegraeve ,

Hope you're having a good week.  In relation to your comment about adding a story in your backlog to address the Digital Interface name field length, do you know when something like this will be worked on and made available to users?  

We have already hit the limit (annoyingly by 1 character so far), and it prevents us from having a standard.   Unless we step away from adding the type of Interface in the name itself (e.g., removing "_API" from the names of APIs), and having to distinguish what they are by the "functional protocol" such as HTTPS or FTP in the detail of the record.

Thanks again for your help.

Kind regards,

Mark

[Bruno De Graeve · Accepted solution]

hello Mark, @markterringon 
Apologies for the late reply. Something went wrong with the notifications.
It's my hope to make this small enhancement available with the next release. Until then, I would change the dictionary and increase the string value from 40 to 120.
Would that size be enough or will you and other customers, still be limited ?

regards, Bruno

[markterringon]

Thanks again Bruno.

I am assuming that would be Yokahama, which I believe is released in May this year.  I think that is a short enough window as we are still collating all our APIs, and happy to keep a shorter naming convention until then.

Thanks again 🙂

Mark

[Bruno De Graeve]

hi Mark, as you probably figured out, it's a bad practice on our side to talk about committed ETAs (cf. "Safe Harbour").

That said, I finished today a Fix Script to upgrade the 'name' max_length from 40char to 150char. If a customer already increased it above 150char, we will not modify it again.

So you know what's coming 😉

regards, bruno