[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Trading Partner Logical Identification based on EDIFACT orX12qualifiers
Dick, Alright - so you have an existing product and you are into the weeds on implementating all this....your trusty Ford may just need a new set of tyres... Message text written by INTERNET:firstname.lastname@example.org >My existing B2B products contain a database of trading partner information that the system administrators are responsible for managing. Trading Partners have no access to this database and that is the safest solution, in my opinion. If you want to make your products trading partner database accessible over the Internet through API's then go for it. But don't make me do the same, it should be my CHOICE, not MANDATED! >>>>>>>>>>>>> I was never for one minute suggesting you should expose your customer base - that's nuts! Only if a new customer wants to add themself to your system and they can be pre-qualified - then business logic says - 'bring 'em in please!'. That's all we're asking for here, an interchange profile. << Also, I never said it was too much work to provide an API (those were your words), my position is this: Mandating the use of a regrep API: - introduces an unnecessary security risk >>>>>>>>>>>>>> What?! If its done right its the opposite! It provides a secondary level of authentication with a trusted source. Is this person really who he says he is? << - is inefficient because it adds an unnecessary remote access to each interchange >>>>>>>>>>>>>> Again - you just cannot say that. Your mileage will vary depending on business use. I can definately say there will be business case where people will absolutely want this - and if you don;t have it then it will hurt ebXML acceptance. << - it's questionable whether or not it adds any real value in terms of interoperability - it should be optional for those ebXMLers who are willing to take the risk and find it useful >>>>>>>>>>>>>> Dick - that's politics, not sound engineering. Let's examine the business semantic interchange needs, the business process needs, and then make objective decisions - I know you're not disagreeing with that - I've laid out a strawman laundry list to get there - feedback please! Thanks, DW.
Powered by eList eXpress LLC