Bel AIF-dokumentdienste direk vanaf X ++ in Dynamics AX 2012
Gepubliseer: 16 Februarie 2025 om 11:23:48 UTC
In hierdie artikel verduidelik ek hoe om Application Integration Framework-dokumentdienste in Dynamics AX 2012 direk vanaf X ++ -kode te noem, wat beide inkomende en uitgaande oproepe naboots, wat dit aansienlik makliker kan maak om foute in AIF-kode te vind en te ontfout.
Calling AIF Document Services Directly from X++ in Dynamics AX 2012
Die inligting in hierdie pos is gebaseer op Dynamics AX 2012 R3. Dit mag al dan nie geldig wees vir ander weergawes nie.
Ek het onlangs 'n kliënt gehelp om 'n Application Integration Framework (AIF) inkomende poort te implementeer om kliënte te skep op grond van data wat hulle van 'n ander stelsel ontvang het. Aangesien Dynamics AX reeds die CustCustomer-dokumentdiens verskaf, wat die logika hiervoor implementeer, het ons besluit om dit eenvoudig te hou en die standaardoplossing te gebruik.
Dit het egter gou geblyk dat daar baie probleme was om die eksterne stelsel XML te genereer wat Dynamics AX sou aanvaar. Die XML-skema wat deur Dynamics AX gegenereer word, is redelik ingewikkeld en dit blyk ook dat daar min foute in Dynamics AX is wat soms veroorsaak dat dit XML verwerp wat volgens ander instrumente skemageldig is, so al met al was dit minder eenvoudig as wat ek gedink het.
Tydens die poging het ek dikwels gesukkel om uit te vind wat presies die probleem met sekere XML-lêers was, want die foutboodskappe wat deur AIF verskaf word, is minder as insiggewend. Dit was ook vervelig, want ek moes wag vir die eksterne stelsel om 'n nuwe boodskap oor MSMQ te stuur en dan weer vir AIF om die boodskap op te tel en te verwerk voordat ek 'n fout kon sien.
Ek het dus ondersoek ingestel of dit moontlik is om die dienskode direk met 'n plaaslike XML-lêer te noem vir ietwat vinniger toetsing, en dit blyk dat dit so is - en nie net dit nie, dit is regtig eenvoudig om te doen en bied eintlik baie meer betekenisvolle foutboodskappe.
Die voorbeeldwerk hieronder lees 'n plaaslike XML-lêer en probeer dit saam met die AxdCustomer-klas (wat die dokumentklas is wat deur die CustCustomer-diens gebruik word) gebruik om 'n kliënt te skep. Jy kan soortgelyke take vir al die ander dokumentklasse maak, byvoorbeeld AxdSalesOrder, indien nodig.
{
FileNameOpen fileName = @'C:\\TestCustomerCreate.xml';
AxdCustomer customer;
AifEntityKey key;
#File
;
new FileIoPermission(fileName, #IO_Read).assert();
customer = new AxdCustomer();
key = customer.create( XmlDocument::newFile(fileName).xml(),
new AifEndpointActionPolicyInfo(),
new AifConstraintList());
CodeAccessPermission::revertAssert();
info('Done');
}
Die AifEntityKey-voorwerp wat deur die customer.create () -metode teruggestuur word (wat ooreenstem met die "skep" -diensbewerking in AIF) bevat inligting oor watter kliënt geskep is, onder meer die RecId van die geskepte CustTable-rekord.
As u eerder 'n uitgaande poort probeer toets, of as u net 'n voorbeeld benodig van hoe die XML op die inkomende poort moet lyk, kan u ook die dokumentklas gebruik om 'n kliënt na 'n lêer uit te voer deur eerder die read () -metode (wat ooreenstem met die "lees" -diensoperasie) te noem, Soos so:
{
FileNameSave fileName = @'C:\\TestCustomerRead.xml';
Map map = new Map( Types::Integer,
Types::Container);
AxdCustomer customer;
AifEntityKey key;
XMLDocument xmlDoc;
XML xml;
AifPropertyBag bag;
#File
;
map.insert(fieldNum(CustTable, AccountNum), ['123456']);
key = new AifEntityKey();
key.parmTableId(tableNum(CustTable));
key.parmKeyDataMap(map);
customer = new AxdCustomer();
xml = customer.read(key,
null,
new AifEndpointActionPolicyInfo(),
new AifConstraintList(),
bag);
new FileIoPermission(fileName, #IO_Write).assert();
xmlDoc = XmlDocument::newXml(xml);
xmlDoc.save(fileName);
CodeAccessPermission::revertAssert();
info('Done');
}
Jy moet natuurlik '123456' vervang met die rekeningnommer van die kliënt wat jy wil lees.