JSDN Connector Development

This section explains you how integrate Services into the Jamcracker Platform. The document also provides details on the technical aspect with respect to Connector development for integration with the Platform.

JSDN Platform Overview

The Jamcracker Platform enables the aggregation and delivery of Services such as SaaS, PaaS, IaaS, and internal application services for Service Provider through distribution channels or for Enterprises through its organizational structure. For Service Providers, the Jamcracker Platform enables the distribution of Services to customer organizations such as SMBs or Enterprises, through a channel that may comprise wholesalers, distributors and resellers. For the Enterprises, the Jamcracker Platform enables centralized visibility and control with respect to the complete lifecycle of the Service within the organization. This includes catalog‐based ordering, provisioning, usage and subscription management of Services across the organization. These lifecycle management functions may be controlled based on organizational grouping e.g. Line of Businesses and department or by functional roles. The Jamcracker Platform provides rich administrative features for both service provider and enterprises including a single point of provisioning, single sign‐on, and settlement for a wide array of heterogeneous Services. Functional components of the Jamcracker Platform include catalogue management, self service enablement, Service and user provisioning, user and subscription management, help desk services, billing and settlement.

Key Jamcracker Platform Terminology

The Jamcracker Platform can support many different types of Services. However for the purpose of this document we shall categorize the Services used in the Platform as:

  • Application Services
  • Other Services

An application could be any Service delivered across the network including web, mobile, desktop, compute, storage or business applications. Some applications are already integrated and currently being distributed through the Jamcracker Platform and include, for example, Microsoft Exchange, Blackberry, McAfee, WebEx WebOffice. The application being distributed through the Jamcracker Platform will require a Connector in order to enable complete customer lifecycle and identity management for the Service.

Services in this category could be any kind of Service such as:

  • Installation Services
  • Migration Services
  • Maintenance Services

An Offer or Service Offer is a specific configuration of a Service that is offered to customers. When a Service is ordered from a store, or a catalogue of Services, enabled through the Jamcracker Platform, it is always ordered as one of the Offers. For example:

  • A SaaS based email mailbox Service could be offered in multiple sizes i.e. as 1 GB, 5 GB or 10 GB offers. Each of these Offers may have its own pricing. This means that there are three Offers of the same Service available for customers to choose from.
  • Using an IaaS example, Amazon EC2 is a Service whereas we might have innumerable Offers (configurations) of the Service e.g. an Offer with 1CPU, 1GB Memory and 10GB of disk and another Offer with 1CPU, 2 GB Memory and 20GB of disk etc.

The term provisioning means to create and configure a company or a user’s account in the target application or Service to enable user access to the target application or Service. When a company buys a Service for consumption by end users, an account for the company will be created in the target application or Service, using the Connector. Similarly when a user is subscribed to a Service in the Jamcracker Platform, an account for the user will be created in the target application, using the Connector.

The de‐provisioning process is a reverse of the provisioning process seen above. When a company or user no longer needs to use the Service, the Service will be de‐provisioned for them. This also means that the company account and any user accounts in the target application will need to be disabled or deleted to disable access to the Service.

Typical Services Lifecycle in the Jamcracker Platform

In this section, we will describe how Services are used and managed in the Jamcracker Platform. A customer is a Small Medium Business (SMB) or Enterprise organization with a number of end‐users who are the ultimate users of Services.

  • The sample Service depicted below is a multi‐tenant, web‐enabled, SaaS application.
  • The chargeback method employed by this application is an automated post‐consumption method where a department is automatically charged periodically.

    Services Lifecycle

    1. Customer registers and places an order for, say, 25 licenses of the Service (e.g. a desktop backup application from a SaaS application provider)
    2. Customer organization is created and provisioned to 25 units.
    3. Customer is provided access to the application.
    4. Customer organization creates users and allocates the units they have ordered.
    5. User of the customer organization are provisioned and provided access to the application.
    6. Users start consuming the application.
    7. A chargeback is generated at the end of every billing cycle.
    8. During the course of consuming the application
    • Steps 4, 5, 6, 7 are repeated in a cyclic manner.
    • Customer can choose to increase/decrease the number of licenses.
    • CRUD/MAC operations are performed.

Introduction to Connector

To begin with, let us understand what a Connector and its functions are. A Connector:

  • Is a program or a component, which integrates a third party application with the Jamcracker
  • Platform for the purpose of Service provisioning.
  • Can communicate organizations and users profiles in the Jamcracker Platform to the application or Service.
  • Can be developed by a Certified Jamcracker Connector Developer who can be a SI (Systems Integrator), an ISV (Independent Software Vendor) or an ASP (Application Service Provider).
  • Can be integrated into Jamcracker Platform on the fly.
  • Manages organization/user identity in the application or Service
  • Enables a zero touch, automated process to provision an organization and user to an application.
  1. This mechanism of integration does not require any knowledge of the Jamcracker Platform and Connector s (Integrations) can be written and tested independently. This is a platform independent approach to integration where a Connector can be developed using the Application’s native language or technology.
  2. The Jamcracker Platform provides all the data required to create an organization or user in the third party application in XML format for integration purposes. This process of creating the entities in the third party application is called Provisioning.
  3. The third party application provider has to expose a Web interface that can accept the XML. The Jamcracker Platform will post the XML request to this Web interface exposed. The Jamcracker Platform will post this request only over a secure layer, using HTTP over SSL (i.e., HTTPS).
  4. The Web interface needs to accept the request from the Jamcracker Platform, needs to read the XML from
  5. POST parameter name “request”, parse the data, and extract required data using a parsing mechanism.
  6. The parsed data is used to create organization or user entities in the third party application.
  7. The application will provide a response back to Jamcracker via a pre‐defined XML format. This response will notify the Jamcracker Platform of the success/failure of the operation and optionally send more information that needs to be populated back in the Jamcracker Platform.
  8. The Jamcracker Platform will accept the XML and fetch the status of provisioning.

The Jamcracker Platform provides six integration points for a Connector to integrate a third party application and manage an organization and user’s identity in the third party application. These events are explained here.

Company Events

Whenever a company/organization subscribes to the Service in the Jamcracker Platform, the Web interface exposed by the application provider will be notified about the event along with the data captured. The Web interface will be responsible for forwarding the request to any interfaces further, if any, to ensure the company/organization creation in the target application.

Whenever a company/organization’s information is updated in Jamcracker Platform, the Web interface exposed by the application provider will be notified about the event along with the data captured. The web interface will be responsible for forwarding the request to any interfaces further, if any, to ensure the company/organization information is updated in the target application.

Whenever a company unsubscribe to a Service in the Jamcracker Platform, the Web interface exposed by the application provider is notified about the event along with any related data that was captured during the unsubscribe event. The web interface will then be responsible for further forwarding the request to any other interfaces, to ensure the company is deleted in the target application.

User Events

Whenever a user is provisioned to the Service in the Jamcracker Platform, the Web interface exposed by the application provider will be notified about the event along with the data captured. The web interface will be responsible for further forwarding the request to any other interfaces, to ensure user creation in the target application.

Whenever a user’s information is updated in the Jamcracker Platform, the Web interface exposed by the application provider will be notified about the event along with the data captured. The web interface will be responsible for further forwarding the request to any other interfaces, to ensure the user information is updated in the target application.

Whenever the Service is de‐provisioned for a user in the Jamcracker Platform, the Web interface exposed by the application provider will be notified about the event along with the data captured. The web interface will be further responsible for forwarding the request to any other interfaces.

Whenever a user is provisioned with Service, the Jamcracker Platform allows the user to Single‐Sign‐On (SSO) to external application from Jamcracker Platform. To enable the SSO feature for the external application, the Jamcracker Platform requires HTML content from external application.

Requests XML

The request XML should confine to the XSD/ DTD provided in the Appendix C. The latest XSD/ DTD can be found on the Jamcracker partner portal.

Service Level Fields:

Service level fields are global to all companies provisioned to the Service. The value is going to remain same for all companies and users. (Example ‐ Exchange mail server URL will be same for all companies/users and hence referred to as global fields).

Builtin Service level fields:

  • serviceName ‐ Name of the Service in marketplace
  • serviceID – Internal Service Id
  • offerCode ‐ Name of the offer in marketplace
  • offerID – Internal offer Id

Company level fields:

These are the fields, which are unique to every company provisioned to the Service. The value is different for every company provisioned. (Example ‐ Exchange mail domain can vary per company).

Builtin company level fields:

  • companyAcronym – Acronym of the company who is ordering the Service. This will be unique value in an instance of the Jamcracker Platform.
  • companyName – Name of the company ordering the Service.
  • licenseNum – The number of subscription licenses ordered by the company.
  • Phone, address1, address2, address3, city – Self‐Explanatory
  • state – State of the company. This valued depends on the country. This is a free text for the country other

Builtin company level fields:

  • companyAcronym – Acronym of the company who is ordering the Service. This will be unique value in an instance of the Jamcracker Platform.
  • companyName – Name of the company ordering the Service.
  • licenseNum – The number of subscription licenses ordered by the company.
  • Phone, address1, address2, address3, city – Self‐Explanatory
  • state – State of the company. This valued depends on the country. This is a free text for the country other than US. Refer Appendix B for valid state codes supported by the Jamcracker Platform
  • country – Country that the company belongs to. Refer Appendix A for the valid country codes supported by the Jamcracker Platform.

User level fields:

These are the fields, which are unique to every user provisioned to the Service. The value is different for every user provisioned. (Example ‐ Exchange mail storage quota can vary per user).

Builtin user level fields:

  • loginName – loginName of the user. This will be unique value in an instance of the Jamcracker Platform and this will never change.
  • password – This represents the password specific to your Service for the user. These passwords are system generated by Jamcracker platform and sent to your Connector. You need to extract this password from the XML and set it in your application as the user’s password. The same password will be used during Single Sign On process (SSO). Note that this password is different from Jamcracker SMC password.
  • firstName – First Name of the user who is getting provisioned.
  • lastName – Last Name of the user who is getting provisioned.
  • email – Email address of the user. This can be modified in the Jamcracker Platform.
  • roleName – Jamcracker roles are defined as ‘ENDUSER’, ‘PROVIDERADMIN’ or
  • ‘ORGANIZATIONADMIN’. If you have a need to define custom roles specific to your application, you can use the same field and define values such as “my_role_name1=my_role_value1; my_role_name2=my_role_value2”. The pattern is name=value pairs of various roles. You can define as many custom roles as you need in this pattern.
  • contactPhone, address1, address2, address3, city – Self Explanatory
  • state – State of the user. This depends on the country user selected. This is a free text for the
  • country other than US. Refer Appendix B for valid state codes supported by JSDN
  • country – Country of the user. Refer Appendix A for the valid country codes supported by the Jamcracker Platform.

Response XML

The response XML should confine to the XSD/ DTD provided in the Appendix D. The latest XSD/ DTD can be found on the Jamcracker partner portal. The attribute ‘name’ and ‘type’ should be same as the request for which the response is being sent.

Fault Code/ Fault String:

If the event is successful then fault code should be “0 (zero)” otherwise it should have some other value. In case of any error, fault string will contain the error description. If there is any data that requires to be saved in Jamcracker Platform, such values should be included in the Response as shown above. Note that the <entity> tag is not mandatory in the response. No built‐in fields should be updated. For SSO event, the response should contain “ssocontent” without which the response won’t be considered as valid. HTML content for SSO should be bound as CDATA content.

The above section of the document explained the Request XML sent from Jamcracker Platform to the vendor and Response XML sent from the vendor’s Connector to Jamcracker Platform.

  • Request XML – Sent from Jamcracker to Vendor’s connector
  • Response XML – Sent from Vendor’s connector to Jamcracker

Please note that the Request and response XMLs need to conform to the XSDs provided by Jamcracker. The structure of the XMLs, element names, and attribute names should NOT be modified.

Checklist:

  • Write Connector using your platform specific technology.
  • XMLs should be confined to the defined DTD/ XSD.
  • No built‐in fields should be present in response XML.
  • Connector to be certified by Jamcracker.
  • Service to be configured on Production systems.

Skill‐Set Requirements for Connector Development

Connectors can be written by developer with the following basic capabilities:

  • Basic Knowledge of XML.
  • 2+ years of hands‐on experience writing XML based programs on the target Programming Language.

Prerequisites:

Maven3 or a later version installed and available (http://maven.apache.org/download.cgi).

Creating Connector Project:

  • From command prompt:

Once maven 3 or a later version installed, run the following command:

mvn archetype:generate -Dfilter=jit-adapter

Enter '1' for the next prompt as shown above.

Where

  • groupId is a unique group which represents your company

E.g. If your company is zyz, the groupId can be com.xyz or org.xyz

  • artifactId is a unique Id which represents your Connector

E.g. If the Connector is for service z, the artifactId can be zservice-Connector

  • version – version of the jar which will be generated
  • package – package of the generated java classes

Refer maven documentation (http://maven.apache.org/) for more details on how to use maven.

The final screen will look like the following:

The above command will generate the connector template files in the following structure:

  1. The code to integrate the target application can be written in the following generated java classes:
    • AuthenticationImpl.java: The method authenticate() of this class should be used to authenticate the request coming from JSDN. AuthInfo object will contain the username/password which is set in the service configuration. If the authentication fails, it should throw AuthenticationException which will be send back as a failed response to JSDN.

  2. CompanyEventsAdapter.java : The Servlet will delegate the JIFRequests to this class' corresponding company event methods. The following event methods are available:
    • createCompany (JIFRequest jifRequest):

      This method will get called when a company orders the offer of the service for the first time in JSDN Platform. JIFRequest will contain all the parameters which are configured as part of the createCompany Event in service configuration. Refer the sample code in the template. You can write the code to create the account in target application.

    • updateCompany (JIFRequest jifRequest):

      This method will get called when a company increase or decrease the license of an already ordered offer in JSDN Platform. The same method will get called again for any company profile update in JSDN. JIFRequest will contain all the parameters which are configured as part of the updateCompany Event in service configuration. You can write the code to push these changes to the target application.

    • deleteCompany (JIFRequest jifRequest):

      This method will get called when a company cancels the subscription of an offer in JSDN Platform. JIFRequest will contain all the parameters which are configured as part of the deleteCompany Event in service configuration. You can write the code to delete this account in the target application.

  3. UserEventsAdapter.java: The Servlet will delegate the JIFRequests to this class' corresponding user event methods. The following event methods are available:
    • createUser (JIFRequest jifRequest):

      This method will get called when a user is assigned to the offer of the services in JSDN Platform. JIFRequest will contain all the parameters which are configured as part of the createUser Event in service configuration. You can write the code to create the User in target application.

    • updateUser (JIFRequest jifRequest):

      This method will get called when a user assigned to the offer updates his profile information in JSDN Platform. JIFRequest will contain all the parameters which are configured as part of the updateUser Event in service configuration. You can write the code to push these changes to the target application.

    • deleteUser (JIFRequest jifRequest):

      This method will get called when a user is unassigned from an offer in JSDN Platform. JIFRequest will contain all the parameters which are configured as part of the deleteUSer Event in service configuration. You can write the code to delete this user in the target application.

    • getSSO (JIFRequest jifRequest):

      This method will get called when a user try to do a single sign on to the assigned offer from JSDN. This method should set a SSO URL into the jifResponse which will be used by JSDN to single sign the user into the target application. The SSO URL should be valid only for a limited time for security reasons.

      All the methods should return either of the following:

      • SuccessResponse: If the operation is synchronous and success, return the SuccessResponse. This response will fulfill the operation in JSDN.
      • WaitResponse: If the operation is asynchronous, return the WaitResponse. This response will create a waiting task in JSDN which can be fulfilled later by a call back.

      If the operation fails in target application, throw an exception with a proper error code and response which will create an error worklist task in JSDN which can be re-executed after rectifying the error. If the exception is thrown because of any invalid data, throw ValidationException and if it is caused by any other errors, throw SystemException.

The template also generates basic JUnit testcases. Sample request and response xmls are generated along with the template in the following directory which can be used to run the basic JUnit testcases.

  • src/test/resources/xmls/requests
  • src/test/resources/xmls/responses

xmls in the above locations can be modified as per the requirements or can be downloaded from https://cloudconnect.jamcracker.com/ after configuring your services. The JUnit testcases can be run by executing the following command in the directory where pom.xml is located.

MVN Test

Building the Connector

To build the Connector, run the following command:

mvn package

The Connector war will be created under target folder which can be deployed in your favorite server.

Running Connector using Jetty:

The Connector template comes along with a jetty server which can be used for testing the Connector in real time.

To run the Connector in the built-in jetty server, run the following command:

mvn jetty:run

The adapter should be now up and running on localhost:8080. The end point URL to consume xmls is http://localhost:8080/provision.

Refer http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin for more configuration information about jetty maven plugin.

Highlevel Architecture

Company Events

User Events

Class Diagram

Appendix C - Request XML DTD/XSD

<!ELEMENT authinfo ( username, password ) >
<!ELEMENT body ( request ) >
<!ELEMENT command ( entitydata+ ) >
<!ATTLIST command name ( create | update | delete | sso ) #REQUIRED > <!ATTLIST command type ( company | user ) #REQUIRED > <!ELEMENT datafield ( name, value ) >
<!ATTLIST datafield datatype ( URL | int | string | date) #REQUIRED > <!ELEMENT entitydata ( datafield* ) >
<!ATTLIST entitydata entitytype ( service | company | user ) #REQUIRED
>
<!ELEMENT header ( authinfo ) >
<!ELEMENT jcprovisionmessage ( header, body ) > <!ELEMENT name ( #PCDATA ) > <!ELEMENT password ( #PCDATA ) >
<!ELEMENT request ( command ) >
<!ELEMENT username ( #PCDATA ) >
<!ELEMENT value ( #PCDATA ) >
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="authinfo"> <xs:complexType>
<xs:sequence>
<xs:element ref="username" />
<xs:element ref="password" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="body">
<xs:complexType>
<xs:sequence>
<xs:element ref="request" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="command">
<xs:complexType>
<xs:sequence>
<xs:element ref="entitydata" minOccurs="2" maxOccurs="3" /> </xs:sequence>
<xs:attribute name="name" type="commandName" use="required" />
<xs:attribute name="type" type="commandType" use="required" />
</xs:complexType>
</xs:element>
<xs:simpleType name="commandType">
<xs:restriction base="xs:string">
<xs:enumeration value="user"/>
<xs:enumeration value="company"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="commandName">
<xs:restriction base="xs:string">
<xs:enumeration value="create"/>
<xs:enumeration value="update"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="sso"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="datafield">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" />
<xs:element ref="value" />
</xs:sequence>
<xs:attribute name="datatype" use="required"> <xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="URL" />
<xs:enumeration value="int" />
<xs:enumeration value="string" />
<xs:enumeration value="date" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="entitydata">
<xs:complexType>
<xs:sequence>
<xs:element ref="datafield" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence>
<xs:attribute name="entitytype" type="entitytypevalues"
use="required"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="entitytypevalues">
<xs:restriction base="xs:string">
<xs:enumeration value="service"/>
<xs:enumeration value="company"/>
<xs:enumeration value="user"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="header">
<xs:complexType>
<xs:sequence>
<xs:element ref="authinfo" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="jcprovisionmessage">
<xs:complexType>
<xs:sequence>
<xs:element ref="header" />
<xs:element ref="body" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="name">
<xs:complexType mixed="true" />
</xs:element>
<xs:element name="password" type="xs:string" />
<xs:element name="request">
<xs:complexType>
<xs:sequence>
<xs:element ref="command" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="username" type="xs:string" /> <xs:element name="value"> <xs:complexType mixed="true" />
</xs:element>
</xs:schema>

Appendix D - Response XML DTD

Note: The latest DTD can be downloaded from the Jamcracker Partner Portal
<!ELEMENT body ( response ) >
<!ELEMENT command ( entityresponse, entitydata* ) >
<!ATTLIST command name ( create | update | delete | sso ) #REQUIRED > <!ATTLIST command type ( company | user ) #REQUIRED > <!ELEMENT datafield ( name, value ) >
<!ATTLIST datafield datatype ( URL | int | string | date) #REQUIRED > <!ELEMENT entitydata ( datafield* ) >
<!ATTLIST entitydata entitytype ( company | user | sso ) #REQUIRED > <!ELEMENT entityresponse ( faultcode, faultstring ) >
<!ELEMENT faultcode ( #PCDATA ) > <!ELEMENT faultstring ( #PCDATA ) > <!ELEMENT jcprovisionmessage ( body ) > <!ELEMENT name ( #PCDATA ) > <!ELEMENT response ( command ) > <!ELEMENT value ( #PCDATA ) >
<?xml version="1.0" encoding="UTF-8" ?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="body">
<xs:complexType>
<xs:sequence>
<xs:element ref="response" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="command">
<xs:complexType>
<xs:sequence>
<xs:element ref="entityresponse" />
<xs:element ref="entitydata" maxOccurs="unbounded"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="name" type="eventName" use="required" />
<xs:attribute name="type" type="allowedEntityTypes"
use="required" />
</xs:complexType>
</xs:element>
<xs:element name="datafield">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" />
<xs:element ref="value" />
</xs:sequence>
<xs:attribute name="datatype" type="xs:NMTOKEN" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="entitydata">
<xs:complexType>
<xs:sequence>
<xs:element ref="datafield" maxOccurs="unbounded"/> </xs:sequence>
<xs:attribute name="entitytype" type="allowedEntityTypes"
use="required" />
</xs:complexType>
</xs:element>
<xs:element name="entityresponse">
<xs:complexType>
<xs:sequence>
<xs:element ref="faultcode" />
<xs:element ref="faultstring" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="faultcode">
<xs:complexType mixed="true" />
</xs:element>
<xs:element name="faultstring">
<xs:complexType mixed="true" />
</xs:element>
<xs:element name="jcprovisionmessage">
<xs:complexType>
<xs:sequence>
<xs:element ref="body" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="name">
<xs:complexType mixed="true" />
</xs:element>
<xs:element name="response">
<xs:complexType>
<xs:sequence>
<xs:element ref="command" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="value">
<xs:complexType mixed="true" />
</xs:element>
<xs:simpleType name="allowedEntityTypes"> <xs:restriction base="xs:string"> <xs:enumeration value="company"/> <xs:enumeration value="user"/> <xs:enumeration value="sso"/> </xs:restriction>
</xs:simpleType>
<xs:simpleType name="eventName">
<xs:restriction base="xs:string">
<xs:enumeration value="create"/>
<xs:enumeration value="update"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="sso"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

Frequently Asked Questions

  1. How do I validate my Request/Response XML to conform to Jamcracker provided XSDs?

    If you are writing a Java Adapter, your code to validate the XML with the XSD will look like this:

    SAXParser parser = new SAXParser();
     
    parser.setFeature("http://xml.org/sax/features/validation",
    true);
    parser.setFeature("http://apache.org/xml/features/validation/sc
    hema",true);
    parser.setFeature("http://apache.org/xml/features/validation/sc
    hema-full-checking", true);
    parser.setProperty("http://apache.org/xml/properties/schema/ex
     
    ternal- noNamespaceSchemaLocation", xsdFile.toString());
    ByteArrayInputStream responseInputStream = new
    ByteArrayInputStream(responsexml); InputSource inputSource =
    new InputSource(responseInputStream);
    parser.parse(inputSource);
  2. My system needs the users to have roles which are not supported by Jamcracker. How do I achieve this?

    Jamcracker Request XML contains a field named as “roleName”. Jamcracker roles are defined as ‘ENDUSER’, ‘PROVIDERADMIN’ or ‘ORGANIZATIONADMIN’.

    If you have a need to define custom roles specific to your application, you can use the same field “roleName” defined by Jamcracker in the Request XML and define values such as “my_role_name1=my_role_value1; my_role_name2=my_role_value2”. The pattern is “name=value” pairs of various roles. You can define as many custom roles as you need in this pattern.

  3. How do I set the password for the user in my application? Jamcracker Request XML contains a field named as “password”. This represents the password specific to your Service for the user.

    These passwords are system generated by Jamcracker Platform and sent to your adapter. You need to extract this password from the XML and set it in your application as the user’s password. The same password will be used during Single Sign On process (SSO). Note that this password is different from Jamcracker SMC password.