A következő címkéjű bejegyzések mutatása: wcf. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: wcf. Összes bejegyzés megjelenítése

2015. december 17., csütörtök

Using és a WCF kliens

Minden IDisposable implementációnál szükséges meghívni a Dispose metódust, hogy felszabadítsuk az erőforrásokat. Kézenfekvő megoldás rá a using blokk használata, mivel egy "finally" ágban automatikusan meghívja. Azonban egy WCF kliensnél a Dispose hívás egyenértékű azzal, hogy a csatornára hívunk egy Close-t. Ez viszont bármikor hibát dobhat, például akkor, hogy a csatorna Faulted állapotban van, mivel olyankor Abortot kellene hívni. Bővebb leírást egy MSDN bejegyzés tartalmaz.

Szerencsére az IDisposable.Dispose virtuális, így felül lehet definiálni. Mivel a generált WCF kliens osztály partial class, így könnyedén elérhető, hogy a using Dispose hívása ne dobjon hibát. Ennek eredménye, hogy ténylegesen a Faulted állapotot kiváltó hibaüzenetet fogjuk megkapni.

Az alábbi partial class-t kell létrehozni, ami nyugodtan implementálhatja az IDisposable interfészt, mivel a ClientBase nem teszi.

public partial class CalculatorClient : IDisposable
{
    #region IDisposable implementation
    void IDisposable.Dispose()
    {
        Dispose(true)
    }
 
    /// <summary>
    /// Dispose hívás. 
    /// Értelmesen kezeli a lezárást akkor is, ha a faulted állapotban van.
    /// </summary>
    /// <param name="disposing">Dispose? (másik lehetőség a Finalizing)</param>
    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            try
            {
                if (State != CommunicationState.Faulted)
                {
                    Close();
                }
            }
            finally
            {
                if (State != CommunicationState.Closed)
                {
                    Abort();
                }
            }
        }
    }
 
    ~CalculatorClient()
    {
        Dispose(false);
    }
 
    #endregion
}

Ehhez továbbá engedélyezni kell a service app.configjában lévő megfelelő ServiceBehavior szekcióban is, hogy benne legyen a hibaüzenet a válaszban. Enélkül csak olyan hibaüzenet jelenik meg, hogy nem sikerült feldolgozni a hibát, mivel nincs bekapcsolva, hogy legyen benne a válaszban.

<serviceBehaviors>
   <behavior>
     <serviceDebug includeExceptionDetailInFaults="true"/>
   </behavior>
</serviceBehaviors>

2013. október 26., szombat

szerveren max. 10 kapcsolat kiszolgálás WCF service-szel

net-tcp alapú WCF dualchanneles kommunikáció folyton elhalt 4-5 kliens esetén. Szerte ágazóan dobálta a communication error-okat. Gyanus volt, hogy 1-2 klienssel ment.
A megoldás végül a WCF alapbeállítások megnézése volt. Mivel itt a kliensek nem is egy csatornát próbálnak folyamatosan életben tartani a szerverrel, és még callback is kommunikálni vele, ezért hamar adódott, hogy az alap 10-es beállítást léphetjük át. Így felhúztam az értékeket: listenBacklog="100" maxConnections="100"
Erre a service el se indult, azonnal faulted állapotba bekerült a kommunikációs objektum az eventlog szerint.

Megoldást azt hozta, hogy a MEX endpointot le kellett lőni (kivenni), mert azzal nem hajlandó 10 fölé menni. Így már hajlandó volt elindulni és a szükséges csatornákat bővíteni.

2012. szeptember 24., hétfő

Windows 8 és WCF

Szánalom a köbön:


WCF szolgáltatás publikálása IIS 8-on

Egy alapbeállításokkal telepített IIS 8-on nem működnek a WCF szolgáltatások, mégpedig azért, mert a webszerver nem tudja, hogyan kell kezelnie az .svc kiterjesztésre érkező kéréseket. Két lépésben taníthatjuk meg neki:

 

1. Vegyünk fel egy új MIME type-ot:
Extension: .svc
MIME type: application/octet-stream
iis8-svc-mime-type

 

2. Vegyünk fel egy Managed HTTP Handlert:
Request path: *.svc
Type: System.ServiceModel.Activation.HttpHandler
Name: svc-Integrated
iis8-svc-handler
És már működik is!
 

2012. január 31., kedd

WCF hívás 400-as hibával, MaxReceivedMessageSizeExceeded

ajax-ból WCF hívásnál (elég nagy a felfelé menő adat) 400 error jött.
WCF Trace-ben egy szép vastag ThrowMaxReceivedMessageSizeExceeded() sor fogadott minket.

Mivel több service-ről van szó és nincs egyesével létrehozva binding/endpoint stb., ezért arra lett szükség, hogy a basicHttpBinding MaxMessageSize property-jét tudjuk változtatni.
WCF 4.0-ás könyv se ír erről semmit...

Gyuri megtalálta:


<standardendpoints>
<webscriptendpoint>
<standardendpoint maxreceivedmessagesize="1500000">
</standardendpoint></webscriptendpoint>
</standardendpoints>


Behaviors után tettük bele a web.config-ba és lám, azóta nincs hiba.
(Nálam már a bindingok egyesével való bevezetésének réme és az ezzel járó szívás, mint fix címek pl. jöttek elő...)



linkek:
http://stackoverflow.com/questions/6341037/wcf-webhttp-service-using-json-increasing-message-size
http://msdn.microsoft.com/en-us/library/ee816915.aspx

2011. november 8., kedd

AJAX - WCF Error handling

Soha nem késő, avagy normális exception kezelés ajax - WCF között:
http://iainjmitchell.com/blog/?p=97
http://iainjmitchell.com/blog/?p=142

2011. július 11., hétfő

Oracle-ből vissza a service-nek

Ez a bejegyzés nem olyan mint a többi megszokott, nem egy végigszopott valamit írok le, hanem megoldást keresek egy problémára, ami nem túl egyszerű.

Röviden:
Van egy oracle adatbázis, sok tábla lesz benne, amiből sokat be lehet cache-elni a service ÉS kliens oldalon egyaránt.
Feladat: a cache-eket valahogy invalidálni kellene, és kikényszeríteni, hogy ha változik alatta az adat.
A periodikus ránézegetést kerülni kellene, így is van elég baja az adatbázisnak.

Lehetséges megoldások:
Két megoldás létezik a fejekben most, egyik az oracle ún. Alert cucca, ami arra van, hogy tud szólni aszinkron valakinek bizonyos eseményekről (is), mint pl insert, update, delete. Ez egyelőre parkolópályán, mert nem erre találták ki, hanem inkább dba-knak való, hogy bizonyos eseményekről küldjön emailt. Éppen ezért alert a neve.

Másik megoldás, hogy egy after* triggerből hívunk egy job-ot, ami aszinkron, na de ennek valószínűleg egy web service-t kellene meghívni (ahogy az első megoldásnak is), amivel ki tudjuk ütni a cache-t.
Ez nem olyan nehéz, triggert írni, ami egy job-ot hív, ami egy web service-nek szól. De a bonyodalom kezdődik, mert ez egy cert-es net.tcp-s wcf service, wsse authentikációval, tehát a cert mellé kellene még küldeni folyton username jelszó párost, ezt összekonfigolni előre láthatóan sok nap szopás.

A kérdés tehát:
Tud valaki valamilyen jó megoldást arra, hogy oracle-ből hogyan szóljunk "fel" egy service-nek, hogy helló, ezt a cache-t ki kellene üríteni, és frissíteni, mert változott?

Jó megoldás jöhet balaton szeletért pl... vagy köszönömért.

2011. július 7., csütörtök

Hülye hiba, WCF & net.tcp & "nagy" wsdl

Érdemes elolvasni, nagyon cumi.
Tegnap beleszaladtunk egy olyan hibába, hogy egyik pillanatról a másikra az svcutil nem tudta legenerálni a kliens proxy-t a wcf service-ünkhöz.
Ami változott, néhány függvényt hozzáadtunk az interface-en. A hibaüznenet annyi volt, hogy a szerver bezárta a kapcsolatot, nem lehet csatlakozni. Próbáltam "felezéssel" kitalálni, melyik metódus a hibás, kikommenteltem felét, svcutil-al generáltam, figyeltem elszáll-e.
A végére maradt 4 metódus, látszólag semmi extra nincs bennük. Mivel ugyanolyan bemenő és kimenő paraméterekkel van már benne "jó" metódus más névvel, kezdett gyanús lenni. Levettem a kommentet, és másik 4-et kikommenteltem, random, tök mindegy mit.
Ugyanúgy ment, tehát NEM a metódusokkal volt baj, hanem azok számával. Nem volt sok, 30-35 metódus, ez meglehetősen kevés ahhoz képest, ami egy service-en általában szokott lenni, de rákeresve a "wcf limit method net.tcp svcutil" kulcsszavakra a következő oldalon egy nagyon szép nyomozás után találtam egy meglehetősen fura leírást és megoldást:
http://social.msdn.microsoft.com/forums/en-US/wcf/thread/d7e36a08-5835-42f8-8eec-8e005cb063c9/

A lényeg, hogy az svcutil-nak is van egy svcutil.exe.config állománya, amiben a net.tcp binding beállításai a default-ok, tehát a már szopások során megismert maxTableCharCount, maxBufferSize, maxReceivedMessageSize stb. paraméterek nincsenek beállítva.

Egy megoldás a problémára:
Kimásoljuk az svcutil-t a konfigjával együtt a proxy generáló parancsunk mellé (vagy bárhova), és abban a konfigban a fenti linken leírt módon ezeket a beállításokat megcsináljuk. És voállá, megy a proxy generálás...

A Microsoftnál egy kicsit jobban átgondolhatták volna ezt... vagy legalább egy normális hibaüzenetet dobhattak volna.

2010. november 15., hétfő

WCF service Https-en keresztül

Elsőre nem tűnik túl bonyolultnak, van egy wcf service, hostoljuk, méghozzá https-en.
Amikor az ember nekiszalad, akkor látja hogy azért van ezzel szopó, mert ugyan a neten soksok cikk van, de viszonylag kevés olyan, amiben minden választ megkapunk a hogyan-okról.
Ez egy egész jó leírás, ha végigolvassuk, mielőtt nekiugrunk, sokat segít.

Ami nem triviális, az a cert generálás a makecert paranccsal, és a "namespace reservation" a netsh-val (win2008). Sok helyen el lehet tolni, de 2 nagyon fontos dolog van:
  1. A legfontosabb talán az, hogy a namespace reservation-nél a gép HELYI ip címét kell megadni, még véletlenül sem azt, ami kívülről esetleg látszik weben keresztül. 127.0.0.1 és localhost pedig gyorsan elfelejtendők!
  2. Amikor a cert-et generáljuk, a CN=valami property-nél mindenképpen azt a domain nevet kell megadni, amin keresztül majd el lehet érni a szolgáltatást (kívülről). Ezt érdmes bevésni az agyba, mert ha simán egy web oldalt szeretnénk https-en publikálni, ott ugyanígy kell a cert-et generálni (tehát ha https://mydomain.com/valamilyenoldal lesz az url, akkor CN=mydomain.com -nak kell lenine).

Sokszor elkövetett konfigurációs hibákra meg talán ez az oldal elég összeszedett (asztal csapkodások közepette érdemes megnézni)

2010. augusztus 5., csütörtök

WCF mélységei, avagy kaparjuk meg a felszínt

Ha esetleg problémát okoz a kliens és a szerver konfig szinkronbantartása. (Ha a szerveren változtatsz valamit, akkor a kliens konfigban is kell)
Megoldás:
http://www.codeproject.com/KB/WCF/ExtendingWCF_PartI.aspx

2010. június 30., szerda

enum és értékkészlete

Nagyon szép szívásba sikerült tegnap belekerülni. DB-ben INT mező, benne egy enum-má alakuló értékkészlettel a BL-ben. EF-fel felolvassuk, majd a POCO objektumba enum-ra kasztolva értékként megy le a kliensre. Az Enum értékkészlete 1,2,3 lehet, de a DB-be sikerült kézzel egy 0 értéket felvenni az init DB részben. A végeredmény egy underlying connection was closed hibaüzenet lett a WCF híváskor, mert nem sikerült szerializálnia az enum-ot a DataContractSerializer-nek. A DAL,BL kódon viszont hiba nélkül végig csúszott az érték, és csak itt pattant el egy eléggé félrevezető hibaüzenettel.
Tehát az underlying connection hibaüzenetről eddig is tudtuk, hogy szerializálási problémát jelent, de most már nem csak azt kell fejbe tartani, hogy valamely típust (nested típust) nem tudja "sorosítani", hanem azt is, hogy az értékkészlettel van problémája szerializálásnál, ami nagy eséllyel egy enum értéke lesz...

2010. április 16., péntek

Jogosultság felhasználónak WCF-es port nyitásra

IIS halatt hostolt service-nek nincs joga WCF alól portot nyitni, akkor a következő lépések hiányoznak:
1. First get the SID of the user running the windows service. Tip: see C:\Documents and Settings\\Local Settings\Application Data\Microsoft\Credentials\

2. Then create a batch file with the followinf content assuming that the httpcfg.exe is installed into the default folder:
@set sid=%1
@set httpcfg.exe="C:\Program Files\Support Tools\httpcfg.exe"
%httpcfg.exe% set urlacl /u "http://+:_portnumber_/servicenamefile.svc/" /a "D:(A;;GX;;;%sid%)"
....
3. Execute your batch file with the SID specified as first parameter, example (this sid is valid only on my local computer!): SetupUrlAcl.cmd „S-1-5-21-329068152-1425521274-725345543-1015”
4. Ensure that the user has right „act as part of the operating system”. (mmc, local computer policy, computer configuration, windows settings, security settings, user right assignment) The snapin is not added by default, you have to add it manually (group policy object editor).
5. Start the windows service and esure that it’s working.

a httpcfg.exe set sort annyiszor kell megismételni, ahány service fájlod van.

Ezzel a paranccsal természetesen le is kérdezhető, tehát ha probléma van egy service elérésével, akkor először csekkold, hogy van-e joga a felhasználónak portot nyitni.