Jeg tror terminologien har endret seg fra aloha-apper til ISV-apper.

Tidligere den største fordelen var at installerte ahola-apper ikke telle mot forskjellige organisasjonsgrenser og kunne fungere med gruppe- og profesjonelle utgaver av Salesforce. I en tidligere Salesforce-utgivelse ble i det minste noen av fordelene overført til alle administrerte pakker.

Ikke mye dokumentasjon ser ut til å bruke begrepet «aloha» lenger. Det er et gammelt blogginnlegg Design en Aloha-app . Innlegget som er koblet til Designe en applikasjon for Gro opp og Professional Edition -siden som nå omdirigerer til Arkitektoniske hensyn for gruppe- og profesjonelle utgaver . Jeg trakk følgende ut av wiki-historikken for den gamle siden:

Videre, som en del av AppExchange-partnerprogrammet, vil den administrerte pakken din være kvalifisert for spesielle tillatelser som lar deg dra nytte av unike fordeler, slik at appen din blir riktig installert og fungerer i GE og PE. Apper som er bygd på Force.com og som har disse spesielle tillatelsene, kalles Aloha Apps . Aloha Apps vil bli vist på AppExchange her .

Ved kvalifisering er en Aloha App Apex autorisert og immun mot visse utgavegrenser. I tillegg, hvis appen din krever API-integrasjon, kan kvalifiserte partnere få API-tilgang til GE- og PE-organisasjoner. For mer informasjon om partnerprogrammet, inkludert kvalifiseringskrav, kan du gå til oss på www.salesforce.com/partners.

Merk: Appen din kan bare være en Aloha-app og motta Aloha-appikonet på AppExchange-oppføringen din hvis den er pakket som en administrert pakke.

Hvordan lage en Aloha-app?

Nå forstår du at det er mange spesielle tillatelser du kan dra nytte av å bygge for GE og PE. Hvis du har bygget en app og du tror den er klar til å jobbe med GE / PE som den er, kan du logge en sak på Partnerportal og opprette en sak som ber om noen av tillatelsene som er nevnt (Apex Authorization, Apps / Objects / Tabs Limit Immunity, og / eller API Access). Merk at søknaden din må ha en administrert pakke tilknyttet oppføringen, og at du må være en kvalifisert partner. For mer informasjon om partnerprogrammet, inkludert kvalifiseringskrav, kan du gå til oss på www.salesforce.com/partners.

Husk at du fortsatt kan trenge å omorganisere appen din for å støtte GE / PE, selv med disse spesielle tillatelsene aktive. Som partner har du rett til forskjellige testmiljøer for å sikre at appen din fungerer som den skal mot GE / PE. Du kan lære mer her .

Jeg tror fremover at du er bedre å følge dokumentasjonen fra Bruke Apex i gruppe- og profesjonelle utgaver

Når du har forsikret deg om at appen din oppfyller kravene til Aloha-status, må du ta opp en sak i partnerportalen og be om at den skal innvilges. Den er ikke automatisk . Det er en spesiell sakskategori tilgjengelig for slike forespørsler.

Kommentarer

• Det ser ut til at Aloha-apper er (eller var) apper som kan kjøres i GE eller PE, og ikke telle også ‘ t mot typiske grenser – se success.salesforce.com/answers?id=90630000000h1rAAAQ
• » Du må være en kvalifisert partner med salesforce.com, og appen din må bestå sikkerhetsgjennomgangen. De aktuelle tillatelsene aktiveres automatisk etter at du har bestå sikkerhetsgjennomgangen. » Aloha-statusen er nå automatisk, ifølge lenken i svaret.
• Aloha, da den ‘ fremdeles kalt av LMA-abonnentfanen, har fremdeles implikasjoner på grenser – spesielt aloha-aktiverte pakker teller ikke ‘ teller mot abonnentens org-faner.

Hva er Aloha:

Aloha var en spesiell status gitt til apper, slik at appene ikke teller mot ulike grenser pålagt av Salesforce.Fordelene som er inkludert:

• Aloha-apper teller ikke mot tilpassede apper, objekter og faner.
• Aloha-apper kan kjøre Apex Code i Group Edition (GE) og Professional Utgave (PE)
• Aloha-apper kan bruke Web Service API for GE og PE

Da Salesforce oppdaterte AppExchange i august 2012, Salesforce sluttet å publisere begrepet » Aloha App. »

Siden august 2012 teller ikke alle administrerte pakker med Salesforce-systemgrenser. Her er Salesforce-blogginnlegget som kunngjør endringen:

http://blogs.salesforce.com/company/2012/08/everything-you-need-to-know-about-the-new-salesforce-appexchange.html

Ber om » Aloha » status:

I hovedsak anser Salesforce nå alle administrerte pakker som Aloha. Så det eneste kravet for at en app skal være Aloha er at den er en administrert pakke.

Du kan imidlertid fortsatt trenge å be om » Aloha » status via partnerportalen.

Når du oppretter din administrerte pakke, åpne en sak med support fra salesforce-partner og be om at pakken din skal være » Aloha aktivert. » I støttesaken din, oppgi følgende:

1. URL-en for installasjon av pakken
2. AppExchange-oppførings-URL

Kommentarer

• Velkommen til siden! Vennligst ikke ‘ ikke be om oppvoter på svarene; stemmegivning er en iboende del av SE-nettverket, og svaret ditt vil bli stemt opp hvis det fortjener stemmer. Når det gjelder å si at de sluttet å bruke begrepet, hadde de kanskje gjort det offentlig, men når du tar opp en sak, må du fremdeles be om Aloha-status!
• Jeg gjorde en i juni i år – uten den ville vår app ikke ‘ t installeres i Professional Edition-organisasjoner på grunn av noen av plattformfunksjonene appen vår bruker. Etter at saken ble sendt inn og avsluttet med kommentaren » Kommentar: Jeg ‘ har aloha aktivert denne pakken. » det fungerte som forventet.
• Under abonnementsoversikt står det fortsatt » Aloha App » med en avkrysningsrute. Appen vår har den, og den måtte aktiveres manuelt, selv om dette var rundt mai 2012.
• Merkelig min erfaring er at den har blitt fjernet fra sakstypen en stund nå (siden den dårlig formulerte august Kunngjøring om 2012 om det kommer), men som andre plakater, må du fremdeles be om det (via en vaniljesakstype i mitt tilfelle), etter å ha fullført sikkerhetsgjennomgang, som igjen krever at du er en Salesforce-partner.
• @Robs Avhenger av hvor teknisk du vil være. Effekten som tidligere ble kalt Aloha Status eksisterer fortsatt (administrerte pakkeapper har spesielle begrensningsfunksjoner), men begrepet brukes ikke lenger, og har ikke lenger en egen søknadsprosess. Når appen din oppfyller kravene (Partnerstatus, Sikkerhetsgjennomgang, AppExchange-oppføring), får appen automatisk statuseffekten uten ytterligere forespørsel nødvendig.