Arbeider med OutSystems Agile Platforms integrasjonsstudio

Les de forrige installasjonene i serien: Komme i gang med OutSystems Agile Platform, lære det grunnleggende i OutSystems Agile Platform og beskrive OutSystems Agile Platform Service Studio-opplevelsen.

En av de viktigste tingene å forstå om Rat Catcher er at kjernefunksjonaliteten innebærer et ganske komplekst stykke kode som er moderat ressurskrevende; spesielt åpner det for en god del nettverkstilkoblinger samtidig for å laste ned innhold, og deretter behandler det innholdet.

Da jeg gikk over til Agile-plattformen for dette prosjektet, visste jeg at det ikke var mulig å implementere denne funksjonaliteten i Service Studio først og fremst fordi Service Studio ikke har bestemmelser for multithreading. En annen sak var at for mye av arbeidet involverte deler av .NET Framework som rett og slett ikke blir utsatt gjennom Agile-plattformen. Men jeg var ikke bekymret - jeg visste tross alt at Integration Studio ville la meg koble søknaden min til denne koden. Integration Studio er verktøyet som brukes til å knytte Agile-plattformen til ekstern kode, enten ved å skrive kode som nye handlinger eller ved å importere eksisterende kode som Handlinger og enheter.

Det første jeg prøvde å gjøre var å bruke Integration Studio til å importere koden og eksponere medlemmene som enheter og handlinger. Selv om dette var vellykket på teknisk nivå, fungerte det ikke bra for mine behov. Fordi jeg i min kode har en klasse der du angir verdier for et stort antall egenskaper, og deretter kaller en "Utfør" -metodikk på forekomsten. Er dette nødvendigvis den peneste eller den "mest korrekte" måten å gjøre ting på? Ikke egentlig. Men C # er det jeg kaller et "substantivorientert" språk, ikke et "verborientert" språk, og algoritmer er virkelig "verb" (kanskje en F # omskriving er i orden?). Sluttresultatet er at det som ble brakt inn i Integration Studio var ganske ubrukelig.

Etter å ha snakket med Miguel Baltazar (OutSystems Solutions Delivery Manager i USA), viste han meg på omtrent tre minutter en bedre måte å håndtere denne situasjonen på. I stedet for å importere koden direkte til Integration Studio, kunne jeg opprette en ny handling i Integration Studio, og deretter redigere koden for den handlingen i Visual Studio. Derfra ville det være et blunk å legge til referanser til algoritmekoden min og kalle den. Jeg gjorde akkurat det ( figur A ), og med bare litt krefter (mest for å kopiere data fra resultatene av koden min til enhetsformatene), var jeg i gang. Figur A

Den opprinnelige implementeringen av utvidelsen for å få tilgang til min algoritme (også kalt Mongoose Engine). Som du ser til venstre, måtte jeg lage to strukturtyper og bruke dem i handlingsdefinisjonen.

Dette fungerte bra gjennom hele utviklingen min, men det var en liten ulempe som tvang en endring, og endringen var veldig fordelaktig til slutt. Du forstår, jeg hadde brukt Parallel Extensions Library (PFx) i algoritmkoden min for multetråden. Da jeg skrev koden, var PFx bare tilgjengelig i .NET 4 beta og som en CTP for. NET 3.5, så koden min ble skrevet i .NET 3.5 og brukte PFx CTP. Problemet var at jeg oppdaget at CTP ikke var lisensiert for faktisk produksjonsbruk. Selv om det var bunnsolid for mine behov, visste jeg at jeg måtte flytte til. NET 4. Jeg spurte OutSystems om Agile-plattformen støttet .NET 4 ennå, og det gjorde det ikke. Dette betydde at jeg måtte pakke inn algoritmekoden i en webtjeneste og deretter konsumere webtjenesten.

Jeg gikk foran og gjorde dette, og selv om det ikke var så ille som jeg trodde det ville være, var det litt smerte involvert. Det største problemet med å flytte til WCF var å distribuere tjenesten på serveren min. Det var en kongelig smerte i nakken, og det var noen aspekter ved å ikke ha et ekte applikasjonsinstallasjonsprogram som forårsaket meg noen problemer (for eksempel ville installasjonsprogrammet jeg laget for min originale testapplikasjon opprette kildene til loggen som ble brukt). Etter noen få bortkastede timer med å prøve å finne ut hva som var galt, fikk jeg hendelseskildene laget, og WCF-tjenesten fungerte. Derfra var det et skrin å peke Service Studio til den utplasserte webtjenesten. Jeg fant en liten feil, som jeg er sikker på at det tekniske teamet vil fikse ganske snart, og du kan se detaljene om problemet på meldingstavlene. Forresten, dette var min første gang jeg nå ut til samfunnet via meldingsforum, og det var en flott opplevelse.

Figur B

Service Studio med MongooseService Web Reference, og den refererte handlingsfronten og senteret i handlingens arbeidsflyt.

Så hva var sølvforet her? Skalerbarhet. Du ser, bakerst i hodet, har jeg vært veldig redd for hva som vil skje hvis Rat Catcher virkelig tar fart. Jeg har en frontend som krever praktisk talt ingen behandling å gjøre, bare litt datavalidering, litt brukerstyring, og det handler om det. Det er litt ledelse for de månedlige rapportene, egentlig bare å angi hvilke jobber som er inkludert og innstillingene på disse jobbene. Men backend-behandlingen er der det virkelige arbeidet blir gjort. Det er her algoritmen blir kalt fra. Min frykt har vært at jeg med tunge belastninger må begynne å legge til servere, ikke for den daglige driften, men for de nattlige rapportgruppene. Nå som jeg har lagt tunge løft i en WCF Web-tjeneste, er dette ikke lenger et problem. Hvis jeg finner ut at de nattlige rapportene er et problem, er det overhode ikke noe problem å skalere WCF Web-tjenesten ut, eller kanskje å flytte den til Microsofts Azure-tjeneste. På det tidspunktet må jeg endre tjenesten for å godta en rekke forespørsler og sende en gruppe resultater tilbake, men det vil bare være en time eller to av jobben.

Mens jeg nå har hovedbehandlingsalgoritmen som blir importert som en webtjeneste direkte i Service Studio, har jeg fremdeles noen andre mindre verktøyfunksjoner som blir brukt gjennom Integration Studio. Akkurat nå måtte jeg gaffle backend-koden min, en gren for .NET 4-behandlingsalgoritmen og en gren for den eldre 3.5-koden som blir brukt av Rat Catcher gjennom forlengelsen Integration Studio. Men så snart Agile Platform støtter .NET 4, vil jeg ta den koden i Integration Studio og henvise til den nyere kodegrenen. Jeg er helt fornøyd med dette, siden koden er låst og ikke kommer til å endre seg snart.

Figur C

Dette er et skjermbilde av hva en bruker ser etter å ha lagt inn et nytt dokument i systemet.

Rat Catcher er nesten klar for sin offentlige beta! Jeg trenger bare å teste det planlagte rapportsystemet. Brukergrensesnittet må forbedres litt, og jeg venter på at grafikkdesigneren skal få logoen til meg før jeg endrer fargeskjema.

J.Ja

Avsløring av Justin's tilknytning til industrien: Justin James har en kontrakt med Spiceworks for å skrive produktkjøpsguider; han har en kontrakt med OpenAmplify, som eies av Hapax, for å skrive en serie blogger, opplæringsprogrammer og artikler; og han har en kontrakt med OutSystems om å skrive artikler, eksempelskode, etc.

-------------------------------------------------- -------------------------------------

Få ukentlige utviklingstips i innboksen Hold utviklerferdighetene dine skarpe ved å registrere deg på TechRepublics gratis nyhetsbrev for Web Developer, levert hver tirsdag. Abonner automatisk i dag!

© Copyright 2020 | mobilegn.com