Próbował już ktoś tworzyć aplikacje do wysyłania JPK zgodnie ze specyfikacją MF? Przebrnąć przez te wszystkie kompresje, kodowanie, generowanie xml, podpis elektroniczny i podłączenie się do bramki?
aby było przejrzyściej dodałem 3 metodę i wyniki dla serwera testowego dla testów oczywiście wystarczą tylko odpowiedzi z serwera testowego, ale chyba po to jest wystawiony serwer pre-produkcyjny aby spać spokojnie i móc wydać aplikację...
Tak muszę doprecyzować. Wysyłałem tylko na bramkę testową i tylko pliki w wersji enveloping - podpis otacza dokument podpisywany - uznałem że będę używał tego formatu.
Na bramce testowej mój plik i plik initupload-enveloping.xades.xml przechodzi w obu procedurach.
Na bramce produkcyjnej mam dokładnie tak jak napisałeś. Jednak mój plik testowy przechodzi przez obie procedury.
Plik initupload-enveloped.xades.xml nie przechodzi ani na bramce testowej ani na produkcyjnej.
@krzyhu7: ok, jeśli znajdziesz rozwiązanie do którejkolwiek z 3 wyżej wymienionych metod (1 i 2 Twojej i 3 mojej) to proszę o info. Chyba nie tylko my jesteśmy zainteresowani rozwiązaniem wskazanych problemów na bramce produkcyjnej a wszyscy czytelnicy tego wątku. Pozdrawiam i dziękuje Tobie jak i użytkownikowi @Gibonowski za przedstawienie dotychczasowych rozwiązań. Jeszcze raz zwracam się z prośbą do użytkowników tego forum o publikację działającego rozwiązania o ile takie istnieje na
@krzyhu7: u mnie bez powodzenia, przynajmniej na tych testowych plikach xml z mf utworzyłem 4 metodę
static string PostXMLData4(string destinationUrl, string requestXmlFile) { var client = new RestClient(destinationUrl); var request = new RestRequest(Method.POST); request.RequestFormat = RestSharp.DataFormat.Json;
cały czas otrzymuje komunikat {"Code":410,"Description":"Przesłane pliki nie są prawidłowym archiwum ZIP.","Details":"ERROR_DECOMPRESS","Upo":"","Timestamp":"2016-07-27T14:46:42+00:00"} ktoś wie o co chodzi? Próbowałem różnych metod kompresji, obecnie używam tej co tutaj ktoś polecił, nie mam już pomysłu o co chodzi...
Mam dokładnie to samo, też już próbuje różne parametry obiektu kompresującego zmieniać i dalej to samo :/ Najpierw przychodzi kod 120, czeka na weryfikacji, a później 410
@Gibonowski: na testowej bramce u mnie działa poprawnie metoda z biblioteki Ionic.Zip
using (var zip = new ZipFile()) { zip.ParallelDeflateThreshold = -1; zip.UseZip64WhenSaving = Zip64Option.AsNecessary; zip.AddFile(fileName, string.Empty); zip.FlattenFoldersOnExtract = true; zip.CompressionMethod = CompressionMethod.Deflate; zip.Save(zipFilePath); } na produkcyjnej nie potwierdzę, bo mam problem póki co z certyfikatem kwalifikowanym...
@Svenson8: piszesz o bramce testowej czy produkcyjnej? U mnie na testowej najpierw 120 później nic nowego, non stop to samo (zgodnie zresztą z informacją na stronie mf, że wyłączyli weryfikację dokumentów na bramce). Raz udało mi się dotrzeć do statusu 200 ale to było ok. 2 tyg. temu, teraz coś pozmieniali :(
chodzi mi o produkcyjny, na testowym jest tylko 120 i dalej nie ma żadnej informacji o poprawności złożenia pliku. Irytujące jest też to, że trzeba długo czekać na odpowiedź na serwerze produkcyjnym.
Właśnie zrobiłem tak: Wziąłem ich initupload podpisałem go, wysłałem ich .aes i mam 200. Więc są 2 opcje: albo źle szyfruje klucz AES albo źle tym AESem szyfruje plik
po użyciu prawidłowego certyfikatu kwalifikowanego udało mi się wysłać na bramkę pre-produkcyjną Za pierwszym razem otrzymałem
{"Code":410,"Description":"Przesłane pliki nie są prawidłowym archiwum ZIP.","Details":"ERROR_DECOMPRESS","Upo":"","Timestamp":"2016-07-28T08:32:23+00:00"} a teraz za każdym razem (także mając dokładnie to samo co za pierwszym razem)
{"Code":100,"Description":"Rozpoczęto sesję przesyłania plików","Details":"","Upo":"","Timestamp":"2016-07-28T08:41:15.5276831+00:00"} czy 100 oznacza, że dokument czeka na przetworzenie, czy to inny błąd?
@mmm234: sam sobie odpowiem po prostu pomiędzy próbami trzeba odczekać trochę, ponieważ ostatnia sesja nie została automatycznie zamknięta. po jakimś czasie mam znowu na starcie 120, a do kolejnej próby 100
#programowanie #sap #erp #jpk
dla testów oczywiście wystarczą tylko odpowiedzi z serwera testowego, ale chyba po to jest wystawiony serwer pre-produkcyjny aby spać spokojnie i móc wydać aplikację...
` static string PostXMLData1(string destinationUrl, string requestXmlFile)
{
XmlDocument requestXml = new XmlDocument();
requestXml.Load(requestXmlFile);
string url = destinationUrl;
var client = new RestClient(url);
var requestInitUploadSigned = new RestRequest(Method.POST);
byte[] bytes = System.Text.Encoding.UTF8.GetBytes(requestXml.OuterXml);
requestInitUploadSigned.AddParameter("application/xml encoding='utf-8'", bytes, ParameterType.RequestBody);
IRestResponse
Na bramce testowej mój plik i plik initupload-enveloping.xades.xml przechodzi w obu procedurach.
Na bramce produkcyjnej mam dokładnie tak jak napisałeś.
Jednak mój plik testowy przechodzi przez obie procedury.
Plik initupload-enveloped.xades.xml nie przechodzi ani na bramce testowej ani na produkcyjnej.
Jeszcze raz zwracam się z prośbą do użytkowników tego forum o publikację działającego rozwiązania o ile takie istnieje na
Na tą chwile wg mnie działa. Problem jest tylko z plikami testowymi.
utworzyłem 4 metodę
static string PostXMLData4(string destinationUrl, string requestXmlFile)
{
var client = new RestClient(destinationUrl);
var request = new RestRequest(Method.POST);
request.RequestFormat = RestSharp.DataFormat.Json;
string certificate = Path.Combine(Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location), "e-dokumenty.mf.gov.pl_ssl.cer");
X509Certificate2 cert = new X509Certificate2();
cert.Import(certificate);
client.ClientCertificates = new X509CertificateCollection(){cert};
byte[] bytes = System.Text.Encoding.UTF8.GetBytes(File.ReadAllText(requestXmlFile, Encoding.UTF8));
request.AddParameter("application/xml encoding='utf-8'", bytes, ParameterType.RequestBody);
IRestResponse response = client.Execute(request);
return response.Content;
}
dla obu plików enveloping
Najpierw przychodzi kod 120, czeka na weryfikacji, a później 410
using (var zip = new ZipFile()){
zip.ParallelDeflateThreshold = -1;
zip.UseZip64WhenSaving = Zip64Option.AsNecessary;
zip.AddFile(fileName, string.Empty);
zip.FlattenFoldersOnExtract = true;
zip.CompressionMethod = CompressionMethod.Deflate;
zip.Save(zipFilePath);
}
na produkcyjnej nie potwierdzę, bo mam problem póki co z certyfikatem kwalifikowanym...
U mnie na testowej najpierw 120 później nic nowego, non stop to samo (zgodnie zresztą z informacją na stronie mf, że wyłączyli weryfikację dokumentów na bramce). Raz udało mi się dotrzeć do statusu 200 ale to było ok. 2 tyg. temu, teraz coś pozmieniali :(
Irytujące jest też to, że trzeba długo czekać na odpowiedź na serwerze produkcyjnym.
Szukam źródła problemu.
Wziąłem ich initupload podpisałem go, wysłałem ich .aes i mam 200. Więc są 2 opcje: albo źle szyfruje klucz AES albo źle tym AESem szyfruje plik
Za pierwszym razem otrzymałem
{"Code":410,"Description":"Przesłane pliki nie są prawidłowym archiwum ZIP.","Details":"ERROR_DECOMPRESS","Upo":"","Timestamp":"2016-07-28T08:32:23+00:00"}a teraz za każdym razem (także mając dokładnie to samo co za pierwszym razem)
{"Code":100,"Description":"Rozpoczęto sesję przesyłania plików","Details":"","Upo":"","Timestamp":"2016-07-28T08:41:15.5276831+00:00"}czy 100 oznacza, że dokument czeka na przetworzenie, czy to inny błąd?
po prostu pomiędzy próbami trzeba odczekać trochę, ponieważ ostatnia sesja nie została automatycznie zamknięta.
po jakimś czasie mam znowu na starcie 120, a do kolejnej próby 100
X509Certificate2 cert = new X509Certificate2();cert.Import(filePath);