- a. "interface prefix"+"sourcesystemname"+"targetsystemname"
- b. "interface prefix"+"somenumber"+"targetsystemname"
- c. "interface prefix"+"somenumber"+"systemname"+"subscribing/publishing"
Here let’s take an example of an interface is developed on naming system "a" as above ser_ABC_XYZ. And most of us dealing with integration get a mails or issues saying:
- 1. Order/ invoice/ customer/ payment etc is not transferred.
- 2. The database is down during next 30 minutes, consider stopping the interfaces also.
- 3. MQ Broker has some problem.
- 4. ABC application is failing to send data to application XYZ.
- a. Message type
- b. Adapter type
- c. Source system
- d. Target system
Message Type description (document), this document will explain the mapping of message type to specific number between. Number of digits should be based on the number of message type we have to use for now and in future, mostly three digits XXX (from 000-999) should be fine.
Message Type - Message code
General ledger - 432
Customer data - 234
Source Target description(document), this document will explain the mapping of source/target system to specific number, code should be of two digits XX. Number of digits should be based on the number of message type we have to use for now and in future, mostly two digits XX (from 00-99) should be fine.
Source/Target system name - Source/Target system code
System1 (Data ware house) - 10
System2 (CRM) - 11
Using our newly defined naming standard we can name the interface from CRM to DW for customer data, with any interface prefix we can have the interface name. For example with interface prefix ser_1123410
With this naming convention and the message type, source and target system description document a developer, technical/functional designer or business user can easily co-relate the interface/service and easy life during development, support and maintenance.
PS: comments, feedbacks, suggestions will be appreciated.
Thanks for the blog post buddy! Keep them coming... devsdata
ReplyDelete