Continue reading
Friday, July 14, 2017
The evolution of scalable microservices
Continue reading
Thursday, January 31, 2013
Getting INVALID_SESSION_ID using Salesforce's SOAP based API
The more calls you make, the more errors you'll get (if you're using the same user to perform this calls)
This is a brief description of what happened to me:
I implemented a process to perform Realtime user provisioning by using Salesforce SOAP based API calls. In a few words this is my process:
- Login
- Generate User Account (Using Connection.upsert)
- Verify if User already exists (query User) to determine if next step will be Update or Insert
- Upsert (Insert or Update) User
- Upsert (Using Connection.upsert) other related objects (custom)
- Logout
This process gets invoked when performing SSO, therefore I get as many executions of this process as users try to access my portal.
There is no pattern on this issue.
This is the error I see in my PingFederate logs: [UnexpectedErrorFault [ApiFault exceptionCode='INVALID_SESSION_ID' exceptionMessage='Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session key' ...
After login is been performed (could be before executing any step before Logout or during Logout) This error is generating incomplete user/accounts in Salesforce (Some objects are not created due to this error)
After a few calls and emails with salesforce Developer Support, I got a clear and simple answer:
"There is no implication by calling only login and no logout()"
"Client applications do not need to explicitly log out to end a session. Sessions expire automatically after a predetermined length of inactivity".
Then, instead of over-thingking this problem and design some complex solutions, just like: Implementing a connection pooling mechanism or making singleton my Connection object. The answer was easier than I thought. Don't call Logout and Login as many times as you need. You'll get the same Session_Id (your session will be refreshed on Salesforce and will remain active), letting Salesforce kill it when I'm not using it.
Cool!
Sunday, June 27, 2010
Saturday, June 26, 2010
WebServices with CXF - Testing using JUnit
As you know JUnit is for Testing, so basically I'm going to test my running/deployed WebApplication by declaring this Test Cases:
This one is just a TestCase which tests my Spring Bean ServiceAnd this fellow tests our WebService
As you can see, we need to link using our Service Interface (LibraryService.class) to this JaxWsProxyFactoryBean instance
That was easy! Isn't it???WebServices with CXF - Configuration files III
Now I'll cover my Apache CXF configuration file
As I said before this is not rocket science. It follows the same logic used in every Spring configuration file, everything is based on Beans tags
If you remember my serviceApplicationContext, I declared a Bean called LibraryService
Well, we're going to make reference to this particular Bean on our CXF configuration file, so we can expose it (We already changed our Interface & Implementation using annotations)
Now if you analyze carefully my CXF configuration file, this section links my Spring Bean (Service) with my endpoint on CXF through implementor & implementorClass attributes, which basically link my Java Code (implementorClass) and my Spring Bean (implementor);
The only thing you must add is "#" character before Spring's Bean name: #LibraryService
Finally, I'm using another attribute called address to declare the address for this WebService, by declaring it as address="/LibraryService", this will be my URI for this WebService: http://localhost:8080/little-library-lite/services/LibraryService
Why /services/LibraryService?? I declared on my web.xml that URL Pattern.
In my next and last entry I'll test this WebService using JUnit, if you want to see the WSDL file for all your available WebServices, you can do it by going to http://localhost:8080/little-library-lite/services
There you'll see a list of available WebServices and by clicking them you'll see each one's WSDL
Sunday, June 13, 2010
WebServices with CXF - Configuration files II
I'll just include my Spring configuration files.
Why files? -I though Spring only needs an applicationConext??? Well... Because I prefer to split configuration files according to it's purpose:
- One will have everything related to the Persistence layer
- and the second one will have all my Business layer -services

serviceApplicationContext
When I met Annotations, I just felt in love with them, because one of the main advantages you gain is small configuration files.
On my next entry I'll cover my Apache CXF configuration file and how it fits.
WebServices with CXF - Configuration files I
I'll show 2 basic configuration files: web.xml & my hibernate configuration file (mapping.cfg.xml)
As you noticed I'm using Spring MVC (see webApplicationServlet), but for now let's focus on Spring and CXF:
My 3 main configuration files are listed here, where the 3rd one is for CXF (really obvious file name) and to enable Apache CXF is so simple, Did you remember XFire?
Now let's see my (small) Hibernate configuration file (which I just called mapping.cfg.xml) Instead of using resource=, I'm using class=, because I don't have any hbm.xml file. I'm mapping directly to the class (due to Java Annotations, my mapping it was declared on each POJO).
Now what do you think? Is not as complex as looks like.
WebServices with CXF - Integrating with CXF II
This is going to be a really small entry, because we're going to finish with my ServiceImplementation.
On the next entries we'll discuss configuration files & finally we'll see everything working (Obviously I'll need to test it).
But before that, let's analyze my implementation:
As I've been doing I'm using a lot of WebServices Annotations
What I did???
- Define service name of the Web Service
- Declare the complete name of the service endpoint interface defining the service's abstract Web Service contract (My Interface)
- And set my targetNamespace: the targetNamespace is used for the namespace for the wsdl:portType (and associated XML elements)
WebServices with CXF - Integrating with CXF I
As I said before on Service Interface & Implementation, somehow we'll have to retake that code to implement CXF, and that's what we're going to do.
I want to expose as WebService my LibraryService and as WebMethods these methods:
- public List
getAllAuthors() - public List
getAllBooks() - public List
getAllEditors() - public List
getAllOnlyEditors() - public BookDTO getBook(Integer bookId)
Ok, everything looks nice, but what happens if my client is asking for a "subService" (WebMethod) which returns AllAuthors, but he/she doesn't expect a WebMethod called getAuthors, retrieveAuthors or returnAuthors.What can we do??? -We're done with our coding and that method (getAllAuthors) is being used in many places in our App.
Are you going to rename your code just because your client doesn't like your naming convention???. Later you'll see my answer. Let's modify my code, first, Interface then Implementation;
By adding Java WebServices API Annotations And don't forget for every method we must declare it like a WebMethod In this case I'm declaring a couple of additional attributes, which basically let me give another name to WebMethod, a different name to my original Java Method - this will be the name available on my WebService/WebMethod (this is the second option for my client)
And finally, what can I do if have logic on this interface that I don't want to make it public (available as WebMethod)???
This is the answer: "Just exclude it"
Sunday, May 23, 2010
WebServices with CXF - My Service interface & Impl
Like with our DTO's, later this code will be having some changes when Apache CXF is called to scene.
Now this is my implementation, as you see I'm becoming fan of the use of annotations. I feel like "NIĆO CHIQUITO" (child) with new toy.In future entries I'll explain the configuration files involved to attach together Hibernate, Spring and Apache CXF.
But for now, let'f finish with Hibernate+Spring part and then we'll integrate with Apache CXF (then we'll talk about confuration files)
WebServices with CXF - My DTO's
For your DTO's youmust apply the same rule like with every Java Bean (getter's & setter's, toString, hashCode, equals & Serialization)
My first step is creating a base DTO with all common fields and methods, then it's just extending from that class. I'll just put 2 examples, Ok?
Later we'll have to retake this objects, because we'll have add some extra lines (anotations) just to make them compatible with our WebServices framework, it will be fun.
Saturday, April 17, 2010
WebServices with CXF - My Pojos & DAOs
You know what, I'll skip these methods on my code, eclipse can do it for you, don't be lazy!!!
And one more thing, as Architect it's a must declaring toString method, because when you're debugging these method it's going to be really helpful, and you know what... declare toString it's a must too.
The next step is explain what are those annotations, well they're Java 6 annotations, so we can skip some configurations and declare them into our code. I'll try to explain as simple as possible these annotations, let's analyze them:
BOOK >-- EDITORIn this case I just declared what I needed to declare: One Editor has Many books using a List of Book, like in every mapping of Hibernate: the most common fetching strategy to be used will be LAZY; basically what I did was linking the current ENTITY by it's PK (mappedBy="editor") to Book
The last thing is just declare which column & attribute will be used to do the JOIN between child and father
You can get more details if you look for that topic in Hibernate official documentation.
And these are my DAO's (I just included 1 as example), others should be similar. Always code oriented to interfaces! Later you'll thank me. In my next entry I will explain my Services and we'll be ready for using CXF.
Saturday, April 3, 2010
WebServices with CXF - Our Database
As you noticed the relations are like this:
AUTHOR --< AUTHOR_BOOK >-- BOOK >-- EDITOR